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The Mission Operations Directorate's 
International Space Station Alpha 
Hardware Familiarization Role 

Kenneth W. Zingrebe, II 

Barrios Technology, Inc. 

Houston, Texas 

The National Aeronautics and Space 
Administration (NASA) Mission 
Operation Directorate's (MOD) On- 
Orbit Maintenance Operations 
Mission Controllers are participating 
in space station hardware Tests and 
Demonstrations in multiple neutral 
buoyancy facilities. This is part of 
the controllers' hardware 

familiarization work in preparation 
to support the astronauts in the 
operation and maintenance of the 
hardware. This paper describes the 
larger context of Mission Controller 
hardware familiarization with 
specifics of participation in the 
Boeing neutral buoyancy tests. Also 
covered is what participation has 
occurred in the past and future plans. 

MOD hardware familiarization as 
discussed in the MOD On-Orbit 
Maintenance Operations Support Plan 
is: 

To develop hardware configuration 
expertise, the MOD personnel 
participate in tests and 

demonstrations of maintainability 
and maintenance procedures on 
mockups: 

Flight Hardware Installation, 
Removal and Physical Integration: 

-The MOD personnel observes 
or participates when flight hardware 
is installed, removed and physically 
integrated. 

Tests and Demonstrations: 

-MOD supplements knowledge 
of design, physical configuration, 
and accessibility by observing or 
participating in tests and 
demonstrations. 

Photo/Video Documentation: 
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This paper was prompted by MOD’S 
participation in the Boeing Space 
Station Hardware Intravehicular 
Activity (IVA) & Extravehicular 
Activity (EVA) Neutral Buoyancy 
Simulation (NBS) Tests at which five 
MOD Maintenance, Mechanical & 
Logistics (MM&L) Section personnel 
attended at various times. Specifics 
of the Boeing tests are used to 
illustrate the MOD hardware 
familiarization process. The MM&L 
participants were the author, Edward 
(Ted) M. Kenny, Rotunda M. 
McDaniel, Richard C. McKeel, 
Munish P. Patel, and Johnny D. 
Wong. The tests were at Marshal 
Space Flight Center, January 17 
though March 4, 1994. Tests were: 

IVA Hardware: 

-Hatch, Common Berthing 
Mechanism (CBM) Controller, 
Crossover Rack 

EVA Hardware: 

-Windows, Avionics Feed 
Through, Water Vent, Heat 
Exchanger, Meteor Orbital Debris 
Shield, CBM. 

During the EVA hardware tests some 
of the EVA section personnel 
participated. The hardware test was 
run under funds from the Space 
Station Freedom (SSF) Program* and 
the hardware are all part of the 
International Space Station Alpha’ 
(ISSA). 

The purposes in the MM&L personnel 
participation were to provide MOD 
on-orbit maintenance support and 
participation in: 

Hardware Familiarization 

Evaluation/Influence of Design 


&o??77 cDsP/ i l 

-MOD uses photo/video 
archival of flight hardware as it 
progresses through manufacture, 
integration, final assembly, ground 
processing and delivery to orbit in 
performing on-orbit maintenance and 
contingency repairs. 
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Maintainability/Human Factors 
Evaluation/Influence. 

Evaluation/Influence of 

Maintenance & Operations Task 
Descriptions. 

Face-to-face Interaction w/ 
Design Engineers 

Ancillary Benefits: 

-Training/Maturation 

-Establish Precedent of 

Test/Demonstration Participation. 

-Work Directly with the Flight 
Crew Operations Division (FCOD) 
(Astronauts and support personnel to 
the astronauts). 

MM&L personnel past participation 
in SSF NBS tests and demonstrations 
were: 

Rocketdyne Tests at 

Oceaneering: 

-Electrical Power System (EPS) 
Robotic Interface and Maintenance 
Operations. 

National Aeronautics and Space 
Development Agency of Japan Tests 
at Marshall Space Flight Center: 

-Three week test of Restraints 
and Mobility Aids, Orbital 
Replacement Unit (ORU) Remove and 
Replace (R&R) and use of Power 
Tool. 

Rocketdyne, Boeing & 

McDonnell Douglas Space Systems 
Company Tests at Johnson Space 
Center (JSC): 

•EPS, Control Moment Gyro, 
and Segment Assembly and R&R 
tasks. 

Summary of Tests: 

IVA Hardware: 

-About two weeks 


-Boeing conducted & subjects 

-Some internal suited 

operations 

EVA Hardware: 

•About five weeks: 

-Three weeks Boeing 
conducted & subjects 


-Two weeks NASA 
subjects (Astronauts & Flight Crew 
Operations personnel) 


-During 

NASA 

runs 

some IVA 

operations 




Live Video 

was 

Available 

During NASA 

runs 

and 

was piped 


back to MOD. 

Fidelity: 

-Mockup: 

-Based on SSF design. 

-Hardware still used in 
new IS S A design. 

-Varied from very high to 

very low. 

-Majority was moderate, 

some high. 

-Placement of crew 
restraints/mobility aids was very 
low. 

-Tools: 

-Varied from very high to 

very low. 

•Majority was moderate. 

-Task Descriptions: 

•Logistics Support 

Analysis Record Task Descriptions 
were used where available, Boeing 
test personnel wrote own if not. 
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-Used photos for 


briefing. 


-As proceeded, modified 
procedures or allowed test subjects 
flexibility. 


-Communication was 

through hydrophone (IVA) & suit 
system (EVA). 


-Test Subjects: 

-5% to 95% of Japanese 
female and US male respectively 


-Experience - past flights 
(Astronauts) to none (Design 
Engineers, Astronauts, Neutral 
Buoyancy Tank personnel. Flight 
Crew Operations non-astronaut 
personnel, MOD EVA personnel, and 
MOD MM&L personnel) 


ones, briefidgs, presentations, 
systems briefs, etc. 

Became familiar with hardware. 

Evaluated/Influenced tool and 
equipment design. 

Evaluated/Influenced system 
and maintenance operations task 
descriptions. 

Conducted face-to-face 

discussions with design engineers. 

Personnel received training/ 
maturation. 

Reestablished precedent of 
test/demonstration participation. 

Worked directly FCOD 

Astronauts and support personnel. 


The tests were used or resulted in 
confirmation or modification of 
operational and maintenance 

activities and the design of hardware, 
tools, and support equipment. 


The evaluations 
and maintenance 
design were based 
factors: 


of the operational 
activities and the 
upon the following 


Participated as test subject. 
Future plans: 

Participate in Future ISSA 
Tests, Demonstrations, Installation 
& Integration Operations, and Photo/ 
Video Documentation. 

Provide test subjects. 


Human factors 


Conduct tests. 


-S afety 

-Accessibility 

-Quality of task instructions 


Quality of design 


Using the design engineers and the 
operators in the actual tests resulted 
in very little resistance to 

recommended changes in the 
equipment or operational and 

maintenance activities. 


MOD Benefits Summary: 


Passed 
within MOD, 
Engineering, 



information to others 
FCOD, Program Office, 
Etc.) through one-on- 


Since the Boeing NBS test and 
because of the good results, 
experience and the recommendations 
from the MOD'S MM&L personnel' 
participation in the tests; there have 
been other tests and demonstrations 
that MM&L has supported. A few of 
these tests/demonstrations and they 
results/uses are: 

An MM&L personnel (Johnny 
D. Wong) initiated an ISSA Tool Fit* 
Check on a Thermal Control 
System(TCS) pump package mock-up. 
The test indicated that a 10" 3/8" 
drive extension should be added to 
the Standard IVA Tool List. A 
reach of 20" is required to remove 
the mounting bolts on the pump 
package. Current tools on the IVA 
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Tool List do not facilitate this 
reach. 

MM&L personnel (Mona Mangal 
and Rolunda M. McDaniel) 
participated in the EVAS5 WETF 
Tests with astronaut crew members. 
The rigid tether operation and 
Payload ORU Accommodation (POA) 
Latching End Effector (LEE) were 
evaluated. The primary objectives of 
the test were reach and access 
evaluation and resulted in 
recommended design changes. 

An MM&L personnel (Mark T. 
Davison) lead a Detailed Test 
Objective (DTO) 668 Advanced Lower 
Body Restraint Test (ALBRT) 
training (in the CCT) for the STS 66 
crew. The DTO is designed to 
provide the crew member lower body 
support during RMS and Camera 
Operations. The Restraint is 

attached to the Aft Flight Deck Panel 
and at the 1SSA robotic work station 
site. 
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ABSTRACT 

The National Space Transportation Policy 
(NSTP), dated August 5,1994 best describes the 
challenge facing today’s aerospace industry. 
"Assuring reliable and affordable access to space 
through U.S. space transportation capabilities is 
a fundamental goal of the U.S. space program". 
Experience from the Space Shuttle Program (SSP) 
tells us that launch and mission operations are 
responsible for approximately 45 % of the cost of 
each shuttle mission. Reducing these costs is 
critical NSTP goals in the next generation launch 
vehicle. 

Based on this, an innovative alternative approach 
to vehicle element processing was developed 
with an emphasis on reduced launch costs. State- 
of-the-art upgrades to the launch processing sys- 
tem (LPS) will enhance vehicle ground opera- 
tions. To carry this one step further, these up- 
grade could be implemented at various vehicle 
element manufacturing sites to ensure system 
compatibility between the manufacturing facility 
and the launch site. Design center vehicle stand- 
alone testing will ensure system integrity result- 
ing in minimized checkout and testing at the 
launch site. This paper will addresses vehicle 
test requirements, timelines and ground checkout 
procedures which enable concept implementa- 
tion. 

INTRODUCTION 


brought about an increased interest in the proba- 
bility of launch (POL) and life cycle costs (LCC) 
associated with current and proposed launch 
programs. High recurring SSP costs have been 
attributed to the “standing army” at the launch 
site who support vehicle ground turnaround op- 
erations. It should be noted that the cost break- 
down from SSPcost-per-flight data, NASA FY'94 
budget inputs to the Office of Management & 
Budget, does not support these beliefs. Of the 
dollars spent on each launch, 27 % is attributed 
to vehicle ground operations at the John F. 
Kennedy Space Center (KSC), see Figure 1 . 

Other/misc. 

5% 



KSC 

27% 


Figure 1. STS Cost Per Flight By NASA Center 


Current funding levels associated with the nation’s The SSP budget at KSC is distributed in eight 
launch systems (expendable and man rated) have categories. While the largest portion of the 
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center's budget is allocated for hands-on element 
processing, it should be noted that approximately 
42% is spent on support activities. The alloca- 
tion of SSP funds at KSC is illustrated in Figure 
2 . 



Launch Ops 
52% 


Figure 2. KSC Funding By Category 

SPC funds are subdivided to encompass major 
functions performed in support of SSP opera- 
tions. remainder being allocated to support func- 
tions. Of the SPC funds, approximately one third 
is devoted to hands-on processing activities with 
the remainder being allocated to support func- 
tions. This is illustrated in Figure 3. 


Systems Engineering 
Support 

L PS/Instrumentation & 7% 

Calibration 
8% 


Program Ops. Support 

10% A 


Other/Misc. 'J 
13% N 



Shuttle Processing 
33% 


Facilities O & M 
15 % 


Figure 3 - SPC Cost Breakdown 


launch. SPC data indicates that a typical STS 
flow, includes six thousand Operations and Main- 
tenance Requirements & Specifications (OMRS) 
which must be satisfied. A cultural change in 
vehicle testing philosophy must be introduced to 
minimize these requirements . This cultural change 
must reduce requirements that drive both inte- 
grated factory and launch site processing. 

BACKGROUND 


The reduction of hands-on processing activities 
can be best accomplished through the reduction 
of ground checkout requirements. While the 
reduction of processing requirements sounds 
simple, the level of confidence in the vehicle’s 
ability to safely achieve mission objectives must 
be maintained. The requirements document de- 
tails procedures that must be performed and the 
frequency of performance in the ground process- 
ing/testing sequence. In order to satisfy vehicle 
design criteria have been met and insure the 
vehicle has been properly tested, all requirements 
must be documented prior to launch. 

The number of test procedures performed for 
each vehicle turnaround determines the amount 
of schedule time required for the processing of 
these space vehicles prior to launch. In the case 
of the STS many of these requirements are dupli- 
cated at both the design center/manufacturing 
facility and again at the launch site because the 
test programs and test equipment at these respec- 
tive facilities are not compatible. The perfor- 
mance of redundant testing results in the escala- 
tion of the LCC of these launch programs. The 
Integrated Factory/Launch Site Processing Con- 
cept identifies & reduces these redundancies while 
satisfying vehicle design criteria and ensuring the 
level of confidence required at the launch site. 


This data supports the need for an alternative 
processing approach which extends to all centers 
thereby reducing overall program LCC by use of 
built-in efficiencies which reduce the number of 
requirements during each step in preparation for 


Our studies assessed vehicle processing of sev- 
eral launch programs (both manned & unmanned) 
which included Saturn/ Apollo, Shuttle, Delta and 
Titan IV. This analysis revealed that in each of 
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these programs much of the factory testing is 
repeated at the launch site. There were several 
reasons for this as listed below : 

• Vehicles are shipped short of equipment to 
meet schedule constraints. 

• Manufacturing completion/vehicle integra- 
tion is performed at the launch site. 

• Modification kits are installed at the launch 
site resulting in system retest. 

• Additional testing at the launch site creates a 
sense of improved reliability. 

• Maintenance is performed on reusable ve- 
hicles at the launch site. 

These reasons were common to all the programs 
we analyzed. This suggests that a processing 
concept which minimizes the time required at the 
launch site for ground test activities of both 
manned and unmanned programs is desirable. In 
order for this to happen several things must occur 

• Vehicle elements must be completely as- 
sembled at the factory (No assembly opera- 
tions are deferred to the launch site). 

• Factory testing is not deferred to the launch 
site. 

• Modification kits are not installed at the launch 
site. 

• Factory and launch site personnel require 
access/input to factory test procedures. The 
launch site must have connectivity to the 
factory and be able to transfer design/build/ 
test data electronically for use in verification 
testing at the launch site. 

• Multiple database access is implemented to 
allow both manufacturing and launch site per- 
sonnel to share data with each exchanging 
their "viewpoints". 

• A system environment which allows for end 
user configuration which links multiple loca- 
tions. 

• Factory and launch site checkout procedures 
and associated software must be similar if not 
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identical. This is imperative in adopting the 
Integrated Factory/Launch Site Processing 
Concept. 

• Vehicle design reflect maintainability influ 
ence including selective operation of redun 
dant systems during the mission. 

Implementation of this processing concept is 
reduced LCC associated with vehicle testing 
which equates to reduced costs per pound of 
payload to orbit. In order to financially compete 
in the international aerospace marketplace this 
concept must be achieved. 

APPROACH 

Our initial studies into the Integrated Factory/ 
Launch Site Processing Concept began in 1990 
with the selection of a vehicle configuration. The 
most applicable data which was currently avail- 
able at the time was STS related. This reason, 
coupled with the fact that Shuttle-C was the 
current NASA concept for a heavy lift launch 
vehicle (HLLV) resulted in the selection of a side 
mount shuttle derived vehicle (SDV). The SDV 
(FIG 4) is made up of the following elements : 

• Side Mount Unmanned Cargo Carrier (new 
element) 

• STS boattail 

• STS based MPS 

• STS based APS 

• Single fault tolerant avionics system 

• External Tank (STS specifications) 

• Solid Rocket Boosters (STS specifications) 

For the purposes of this study we felt the SDV 
would make maximum use of STS resources & 
technologies and effective comparisons could 
easily be made between the two. In addition the 
SDV would be capable of: a) utilizing existing 
KSC facilities with little to no modifications, b) 
STS ground processing procedures with minor 
revisions, c) STS databases and d) accommodate 
orbiter payloads. While this study focused on a 
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side mount SDV, the concept is directly appli- 
cable to the current RLV concepts. 



Figure 4. SDV Configuration 

After configuration selection, the STS OMRSD 
was analyzed for multiple systems which were 
common to both STS and SDV. The selected 
systems were : 

• Auxiliary Power Unit (APU) 

• Communications & Tracking (C&T) 

• Data Processing 

• Electrical Power Distribution & Control 
(EPD&C) 

• Flight Controls 

• Guidance, Navigation & Control (GN&C) 

• Hydraulics 

• Main Propulsion System (MPS) 

• Operational Instrumentation (OI) 

• Purge Vent & Drain (PV&D) 

• Reaction Control System (RCS) 

For each of these systems an analysis of the 
OMRSD and the Operational & Maintenance 
Plan (OMP), which tracks OMRSD status, was 
conducted. The OMRS and OMP were used 
because these documents are a) current, b) 
readily available and c) applicable to SDV. 

At this point it should be noted that OMRSD and 
OMP requirements with an effectivity other than 


those for first vehicle flow or all vehicle flows 
were not considered since they are not applicable 
to SDV. From this analysis, it was also deter- 
mined where the OMRSD/OMP requirement was 
satisfied (factory, launch site or both). For each 
requirement satisfied at the launch site the Opera- 
tional Maintenance Instruction (OMI) was noted 
and documented. The OMI is the detailed plan- 
ning/work document for test and maintenance 
activities used at the launch site. Matrices were 
developed cataloging data for each of the systems 
listed: 

• OMRSD requirement number 

• Title 

• OMI number and sequence 

An analysis of the Test Requirements Specifica- 
tion Document (TRSD) was initiated. The TRSD 
defines the work required at the manufacturing 
facility in the construction of a new vehicle. 
Using data acquired from the manufacture of 
OV-105 (Space Shuttle Endeavour), we were 
able to determine the TRSD equivalent to the 
OMRSD where applicable. For each TRSD 
equivalent requirement the implementing Test 
Checkout Procedure (TCP) was identified. TCP's 
are used at the manufacturing facility to direct 
manufacturing test procedures - TCP's & OMI's 
are similar in nature with the major difference 
being the location at which they are performed. 

Once all this data was collected the OMRSD/ 
OMP matrices were expanded to include the 
following information : 

• TRSD requirement number 

• TCP number and sequence 

• Remarks 

From these matrices a master matrix which docu- 
mented the total test requirements to be satisfied 
for a ground processing flow was developed. An 
analysis of this matrix substantiated our belief 
that a high degree of redundancy existed in the 
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testing performed at both the manufacturing fa- 
cility and the launch site. 

Following this analysis of the OMRSD/TRSD 
data, the next step was to determine the amount of 
time spent on test procedures utilized at both the 
manufacturing facility and the launch site. Once 
this was determined the next step was to highlight 
the non-equivalent items and the duplicative test- 
ing which occurred. From this we were able to 
calculate timelines for each of these items as well 
as the time required to run a complete checkout at 
the manufacturing facility. 

Timeline development for each of the systems 
previously discussed was achieved in one of 
three methods : 

• Use of timelines contained within the indi- 
vidual OMI's where available 

• Use of as-run timelines where available 

• Use of manufacturing timelines from Space 
Shuttle Endeavour 

Timelines which are contained within the OMI's 
are an estimate of the time required to run a 
complete procedure. OMI as-run timelines can 
either be for a complete procedure or any number 
of sequences from the procedure; however, as- 
run data gives a more realistic insight into the 
actual time required to complete the procedure 
and allows for more representative schedule 
forecasts. Timelines acquired from the manufac- 
ture of the Space Shuttle Endeavour used both 
estimated and as-run data. 

For this effort it was necessary to determine 
which sequence(s) of the OMI were required to 
satisfy the OMRSD requirements. When this had 
been determined, timelines were redlined to en- 
sure that only the required sequences of the OMI 
were incorporated into the revised timelines. 
Throughout this area of our studies we focused on 
reducing launch site activities without jeopardiz- 
ing the integrity of the launch vehicle. One 
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reason for this is when the vehicle is tested at the 
manufacturing facility a small contingent of per- 
sonnel supports this testing. At the launch site the 
infrastructure required to support vehicle testing 
is broader in scope and therefore is more costly. 
Also, manufacturing operations are run on a 2 
shift per day work schedule while the launch site 
utilizes both 2 & 3 shifts per day. These reasons 
alone support the transfer of test activities from 
the launch site to the manufacturing facility. 

Based on our analysis of the OMI/TRSD data and 
the timelines which were developed we were able 
to look at the Integrated Factory Timeline and 
determine which redundant testing could be trans- 
ferred from the launch site to the manufacturing 
facility. This resulted in a longer test program at 
the factory; however, the horizontal turnaround 
activities at the launch site were reduced from 
approximately seventy days to nine days. Figure 
5 shows the manufacturing test timeline for the 
recently completed Space Shuttle Endeavour and 
projected timelines for the manufacture of the 
SDV which includes testing transfered from the 
launch site to the manufacturing facility. The 
difference is neglible while the savings at the 
launch site is significant. It should be noted that 
these savings can only be realized if the guide- 
lines listed earlier are adhered to. 

GROUND CHECKOUT SYSTEM CONrFPT 

A launch processing system concept that en- 
hances the inter- and intra- operability between 
launch site and manufacturing processing was 
developed. The launch processing requirements 
were based on specifications from LPS upgrades 
at KSC. To achieve the goal of reducing launch 
site activities by enhancing the commonality with 
the manufacturing process, the following items 
were assessed in the determination of the system 
architecture requirements : 

• Common checkout philosophy (factory/ 
launch site) 
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. Common checkout equipment the vehicle idiosyncrasies, failure flags and fail- 

• Common ground software ure trend analysis to be easily accessible by either 

• Launch site input to factory checkout manufacturing or launch site personnel. 

• Launch site real-time monitoring/control A system environment that allows for an end- 



Figure 5. Integrated Factory Checkout Timeline 


This architecture incorporates the concept of a 
ground infrastruc- 
ture data/communications link in which manu- 
facturing and launch site personnel can be elec- 
tronically linked as illustrated in Figure 6. 

With this architecture, factory and launch site 
personnel are able to have access/input capability 
to test databases, real-time test support, post-test 
anomaly resolution and verification testing. 
Multiple databases and their access will be im- 
plemented in a way that allows for manufactur- 
ing and launch site personnel to share data with 
each having their own "viewpoint". This allows 


user configuration that is linked with multiple lo- 
cations was a prime criteria. This is necessary to 
allow for the incorporation and redistribution of 
equipment necessary to execute test sessions by 
multiple factions. This environment has to be 
capable of accommodating application software 
that can be executed in multiple locations based 
on system throughput or the time critical nature 
of the data that is being generated and recorded. 
To incorporate these diverse criteria a distributed 
environment is needed that is transparent at the 
application, user and network level. 

A user environment needs to be able to operate in 
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Figure 6. Ground Checkout System Concept 


a consistent fashion over multiple platforms to 
allow for high resolution graphical display and 
character based consoles where appropriate. This 
will keep costs in proportion to task utilization. 
Training costs and associated overhead will be 
reduced especially in high turnover positions or 
with a vast number of users. In addition, person 
nel will become more productive and confident 
in the production of their tasks. One way to 
enhance this criteria is to provide a consistent 
user interface that provides help checks for po- 
tentially disastrous commands, resolves conflicts, 
brings conflicts to the user’s attention and auto- 
mates tedious lengthy commands. This interface 
must also be capable of execution on multiple 
platforms without multiple user interfaces. 


SUMMARY 

Ground processing costs can be significantly 
reduced by adopting this concept. It should be 
noted that a paradigm shift must occur within the 
aerospace community (private sector & govern- 
ment) in order to implement this concept. Use of 
the concept will reduce the number of induced 
failures which have occurred at the launch site 
during STS testing. Using data from testing at the 
manufacturing facility, launch site personnel can 
develop a knowledge base for each vehicle which 
can be used at the launch site during acceptance 
testing to verify that the thresholds levels which 
were recorded during manufacturing tests have 
not changed during transportation and handling. 
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Test personnel at both sites are able to interface 
with the system and display data in recognizable 
formats which reduces training requirements. 
Precedence for this concept exists in the form of 
the planned STS launches from the Vandenberg 
Launch Site. In addition to reduced LCC associ- 
ated with ground testing, there is a savings to be 
gained from reduced facility complexity. The 
goal is to adapt this concept to the RLV program. 
A major criteria of the RLV program is to provide 
a launch vehicle which is both operable and 
dependable while minimizing program LCC. Pre- 
liminary results indicate that the application of 
the Integrated Factory/Launch Site Processing 
Concept can be readily applied to the RLV pro- 
gram and be instrumental in achieving NSTD 
goals. 
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Abstract 

The Hubble Space Telescope First Servicing Mission is a major accomplishment for NASA and has drawn world-wide 
attention and interest. The extravehicular servicing and repair activities performed by the STS-61 crew were the most 
ambitious ever undertaken. Their unprecedented success in performing on-orbit repair and maintenance particularly 
in correcting the aberration in the primary mirror, has enabled the HST to provide sensational images and the 
anticipation of exciting scientific discoveries. Although the whole world watched the televised logistics activities (on- 
orbit maintenance) that took place in space, few are aware of the time and effort that went into planning and executing 
the space logistics that takes place with our feet on the ground. This paper addresses a major part of that effort - the 
Packaging, Handling, and Transportation (PH&T) activities required to ship the GSFC HST space flight hardware and 
ground support equipment to KSC for launch and the post launch return to GSFC. It addresses the logistics and 
transportation planning for the containers for the Solar Array Carrier, the Orbital Replacement Unit Carrier and the 
Flight Support System and their transporters, and the over land and water portions of the shipments 
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Introduction 

• In December 1993, millions of people around the world 
watched their television sets as astronauts of Space 
Shuttle Endeavour, STS-61, carried out NASA's most 
ambitious and longest duration servicing mission, the 
repair of the Hubble Space Telescope (HST). The 
success of this mission is now history. The solor arrays 
and miscellaneous Orbital Replacement Units (ORUs) 
were replaced. The Hubble's most notorious problem, 
blurred images caused by aflawed mirror, was corrected 
by installation of the Corrective Optics Axial 
Replacement (COSTAR) and a modified Wide Field/ 
Planetary Camera (WF/PC). Scientists now delight in 
the knowledge of the clear images and data being 
provided by the refurbished and repaired HST. 

Logisticians can take great pride in the success of the 
on-orbit maintenance and servicing of HST and the 
engineering, planning, and execution by the 
"logisticians" of the HST team. As any logistician can 
tell you, Maintenance Planning is a primary element of 
logistics. The HST was designed and built to be 


maintainable, serviceable, and refurbishable on orbit. 
It was designed for supportability - a goal for which 
logisticiains continuously strive. The success of the 
HST Fi rst Servicing Mission focused attention on "space 
logistics" or the logistics of supporting systems in 
space. However, contributing to the HST success 
were other logistics efforts that were not nearly as 
glamorous, nor attention getting, as the activities in 
space. These efforts were the logistics activities that 
took place in support of the mission with our feet on the 
ground - the Packaging, Handling & Transportation 
(PH&T) of the HST flight hardware and support 
equipment prior to and post launch. The "logistics in 
space" has received the attention and recognition it 
rightly deserves. This article will focus on the "earthy" 
logistics of the planning and effort required to safely 
deliver the flight hardware and support equipment 
required for the mission from the HST project test and 
integration siteatGoddard Space Flight Center(GSFC), 
Maryland, to the launch site at Kennedy Space Center 
(KSC), Florida. 
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The Team 

Responsibility for mission planning, engineering, and 
test and integration of flight hardware and support 
equipment resides with the HST Project Office/Code 
442 which is located at GSFC in Greenbelt, Maryland. 
The Logistics Management Division/Code 230 at GSFC 
provides the HST Project with logistics expertise and 
resources required to support the HST servicing 
missions. 


a) Flight Support System (FSS) 

b) Orbital Replacement Unit Carrier 
(ORUC) 

c) Solar Array Carrier (SAC) 

The FSS is the approximately fifteen foot diameter ring 
mounted in the rear of the shuttle bay. The astronauts 
capture the HST with the Remote Manipulating System 
(RMS) robot arm and secure it to the FSS and shuttle, 
providing a stable platform for HST servicing activities. 


The Hardware 

The First Servicing Mission called for various activities 
as replacement of components and ORUs such as the 
Gyro Electronic Control Units, Magnetometers, and 
Solar Array (SA) Drive Electronics (SADE). Other 
major activities were the replacement of the SA and 
installation of the WF/PC II and COSTAR. As well as 
the flight hardware to be replaced or installed, the First 
Servicing Mission (FSM) required various items of 
flight support equipmentto transport the flight hardware 

in 


The ORUS is a cradle housing the ORUs and tools for 
the mission and is positioned in the shuttle bay in front 
of the FSS. The astronauts remove the "new" ORUs 
from the ORUC for installation into the HST and place 
the "old" ORUs into the ORUC for return to earth. 

The SAC is a platform positioned forward of the ORUC 
in the shuttle bay and is used in a similar fashion for the 
solar arrays as the ORUC for ORUs. Because of 
difficulties during the actual mission, one of the solar 
arrays was cast off into space instead of being fastened 
to the SAC for return to earth. 


the Endeavour bay to the HST and to assist in the 
servicing operations. The principal pieces of Flight 
Support Equipment (FSE) were the: 


In addition to the Flight Hardware and FSE, Ground 
Support Equipment (GSE) was required to be shipped 
from GSFC to KSC in support of the mission. Although 



Fig. 1 Endeavour’s cargo bay showing the Solar Array and Orbital Replacement Carriers and the Flight Support System 
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the GSE required over twenty tractor trailers for 
shipment, it was the transportation of the Flight 



Fig. 2 The LDEF, Tube Truck, & GRO Transporters on ET Barge. 


Hardware and FSE that provided the greatest logistics 
challenge and required the most planning and effort by 
the engineers and logisticians. 

The Challenge 

Logisticians from the Logistics Management Division/ 
Code 230 worked with the HST Project Office/Code 
442 engineers to conduct transportability analyses, 
identify and evaluate alternatives, conduct feasibility 
studies, evaluate container designs, prepare cost 
analyses, recommend modifications, identify potential 
contractor capabilities, prepare transportation plans, 
and coordinate logistics activities. A Space Support 
Equipment Logistics Working Group (SSELWG) was 
created and chaired by the HST Project Carrier Manager 
to foster communications, maintain schedules, 
interchange information, and manage the myriad of 
details and activities required to plan and execute the 
movement of the flight hardware to KSC. The challenge 


facing the SSELWG was to identify and satisfy the 
requirements for economically and safely transporting 
program critical space flight hardware and FSE from 
GSFC to the launch site. 

The Requirements 

The major pieces of FSE, the FSS, ORUC, and SAC, 
require environmentally controlled containers for 
shipment. These pieces of FSE are also relatively 
large, about fifteen feet across the trunion supports, 
and consistent with the inside dimensions of the shuttle 
bay. Therefore, relatively large containers had to be 
sought that could be environmentally controlled and 
capable of being transported over the road, since 
GSFC has neither an airfield nor waterfront. Two major 
alternatives forcontainer/transporters were considered. 
Existing container/transporters were sought that could 
be modified to satisfy HST's requirements and the 
feasibility and cost of building new container/ 
transporters were assessed. Looking for existing 
containers was the first choice. Standardization, multi- 
purpose, reutilization, recycling, cost avoidance, least 
life-cycle cost, etc. are all buzz words the logistician is 
familiar with and using an existing container would 
appear to provide the most benefit. 

The Solutions 

GSFC had a container that was built for another of its 
spacecraft, the Compton Gamma Ray Observer (GRO), 
that appeared to have potential for reuse. The GRO 
container/transporter was stored in the vicinity of KSC 
awaiting disposition decision. Since GRO was a shuttle 
payload, the internal dimensions of the container would 
be suitable for HST hardware. The GRO was 
transported by C-5 aircraft so it was obviously air 
transportable. However, the GRO was shipped from 
one airfield in California to another at KSC and over 
public road transport was not a consideration. The 
roller flatbed that was part of the GRO container/ 
transporter was about five feet high and was used as 
a loading platform for the C-5 aircraft. Its transport 
purpose was for short run, slow speed, surface transport 
from manufacturer's plant to aircraft and from aircraft to 
launch processing facility. It was not intended to be an 
over road transporttrailerforthe GRO. The5ft. added 
to the 13 ft. height of the GRO container made the 
container/transporter over 1 8 ft. tall and much too high 
to pass underthe overpasses in the GSFC area and get 
from or to Andrews AFB, Maryland, the nearest C-5 
airfield. The height problem was readily overcome by 
being able to use a double-drop low-boy trailer that 
Code 230 had procured for transporting other GSFC 
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payload containers. The new trailer was only 2 ft. high 
and loaded with the 13 ft. GRO would make a total 
height of 15 ft. which could pass under most of the 
overpasses in the GSFC vicinity. The height problem 
was solved, but then there was another formidable 
problem with the width. The GRO container was 1 8 ft. 
wide. Sixteen feet is the maximum width Florida will 
allow with a waiver to their restrictions for use on their 
roads. Some of the other east coast states won't even 
allow 16 ft. The width of the GRO, being an 
insurmountable problem, meant that if used, it would 
have to be restricted to transport by air or by water. The 
State of Maryland would allow overthe road movement 
of the 1 8 ft. wide GRO from the airfield at Andrews AFB, 
orthe Baltimore/Chesapeake Bay waterfront, to GSFC. 
At this point HST knew it had a container that could be 
used for air or water transport of at least one of its three 
pieces of flight hardware. All that had to be done was 
get it from KSC to GSFC. A USAF C-5 mission to 
transport the GRO from KSC to Andrews AFB would 
cost about $100,000, not including the $3,000 for 
rigging to get the GRO off the roller bed and on to the 
low-boy and then the escorted convoy over road 
movement to GSFC. These transportation costs now 
added new factors to the container/transporter decision 
process. When the cost of transport of the GRO starts 
to approach what it might cost to build a new container 
for perhaps more than one item, maybe it is not more 
cost effective, nor the wise decision, to reuse the old. 

While the logisticians and engineers were pondering 
the pros and cons of using the GRO container/ 
transporter for one piece of flight hardware, they were 
also trying to determine what to do about the other two 
pieces. Estimates to build new containers ran from 
$1 50,000 to over $1 million, with varying schedule and 
technical risk factors to be considered and evaluated. 
The search for container/transporters already in 
existence continued with most being eliminated as not 
large enough to suit the HST needs. As well as GRO, 
there was another large container/transporter at KSC. 
Thisone belonged to Langley Research Center( LaRC) 
and was used to transport the Long Duration Exposure 
Facility (LDEF) from LaRC to KSC. The LDEF was to 
be recovered from orbit by the shuttle and returned to 
earth. The LDEF container/transporter would be 
required to return the LDEF to LaRC. The GSFC team 
contacted LaRC and determined that the LDEF had 
potential and might be made available to GSFC. After 
numerous technical interchanges, engineering 
analyses, and drawing reviews, it was concluded that 
the GRO container would carry the SAC with only 
minor modifications to the trunion supports. It was also 
determined that the LDEF container, with more 


extensive modification, could carry both the ORUC and 
FSS. Technically, HST had a handle on resolving its 
container/transporter problems. The logisticians 
attached the logistics problems associated with the 
economical movement of such large container/ 
transporters. 

The Modifications 

The LDEF was designed to be transported by barge 
and because of the inadequacy of its running gear and 
like GRO, its size was not suited to over road travel. 
The LD EF was towed slowly from LaRC to the waterfront 
at Langley AFB where it was loaded on a barge for 
shipment to KSC. Neither at LaRC, nor KSC, did the 
LDEF have to travel on public roads or pass under any 
overpasses, so its height and size presented no problem. 
Unlike GRO, the LDEF containercould not be removed 
from its transporter/trailer. The container was 
structurally an integral part of the trailer and could not 
be removed and placed on a low-boy trailer. The 
LDEF, with its domed roof was about 18 ft. high and at 
that height, even with waivers from Maryland for over 
road movement, would not be able to pass under the 
overpasses between the Chesapeake waterfront and 
GSFC. To be able to get the LDEF container to GSFC, 
it was decided to have it modified at LaRC. Codes 442 
and 234 worked with LaRC to identify, select, and 
award a contract to a fabricator in the LaRC area to 
modify the LDEF container/transporter for the HST 
ORUC and FSS. 

The LDEF was returned to LaRC and the selected 
contractor by the same mode that it was brought to 
KSC, by barge. The NASA External Tank (ET) barge 
ferried the LDEF from KSC to LaRC. Code 230 
negotiated with LaRC and Marshall Space Flight Center 
(MSFC), the owner/operators of the ET barge, to 
transport the GRO along with LDEF. This got GRO to 
Virginia, avoiding the expense of a C-5 flight. LaRC 
stored the GRO container/transporter until the 
modifications to the LDEF were completed and then 
both LDEF and GRO were shipped by barge to GSFC. 
LaRC worked with GSFC to oversee the contractor's 
completion of the modifications. The running gear of 
the trailer was replaced with one that would satisfy 
Department of Transportation (DOT) requirements for 
over the road use. Air bags were installed to provide 
air-ride shock absorption for the payloads and the 
capability to raise or lower the height of the container to 
pass under overpasses. The domed roof was replaced 
by a flat one which reduced the height of the LDEF to 
between approximately 1 5 and 1 6 ft., depending on the 
inflation of the air bags. Trunion support structures 
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were constructed for the FSS and ORUC and new 
external container walls were built. The Environmental 
Control System (ECS) was also modified and adjusted 
for HST requirements. When the modifications were 
complete, Code 230 executed their transportation plan 
for shipping both LDEF and GRO by barge from LaRC 
to GSFC. 

Transportation of Container/Transporters to 
GSFC 

At LaRC the GRO container was removed from the 
roller bed trailer upon which it had been shipped from 
KSC and positioned on the double-drop low-boy 
provided by Coce 230 for over road transport. The 
LDEF and GRO container/transporters were towed 
from LaRC across the Langley AFB runway to the 
waterfront where a commercial shallow water barge 
and tug awaited. Since a prepared pier/dock was not 
available, Code 230 arranged for a commercial rigger 
to construct a loading area/ramp from the shore to 
barge, enabling the transporters to be backed onto the 
barge by the tractors. The tug captain held the barge 
in place with the use of the tug's engines until loading 
was complete. The barge was then towed up the 
Chesapeake to the Defense Logistics Agency Depot 
waterfront area at Curtis Bay, just south of Baltimore. 
After off loading at Curtis Bay, a convoy of the 
transporters, commercial tractors, support equipment 
trucks, government, commercial, and DOT escort 
vehicles, and local and state police, was formed for the 
over road trip to GSFC. The convoy could not depart 
until after midnight to comply with the Maryland permit 
restrictions for the movement. Upon arrival at GSFC, 
the container/transporters were positioned in the vicinity 
of the space flight hardware for Environmental Control 
System (ECS) testing and future loading of the flight 
hardware for shipment to KSC. The movement of 
container/transporters by barge and over the road from 
LaRC to GSFC served to provide logistics planners 
with a "dry run" of the transportation concepts they 
planned to utilize for the HST First Servicing Mission. 
All went successfully as planned. 

Transportation of Mission Hardware to KSC 

ET Barge . Code 230 arranged with MSFC for the HST 
flight hardware container/transporters to be transported 
from Curtis Bay, Maryland, to KSC by the NASA ET 
barge. The shipment dates were coordinated with 
MSFC to coincide with the shipment of an ET to KSC 
from Michaud, Mississippi. This coordination enabled 
the HST project to pay for bringing the barge to Curtis 
Bay only from KSC and not the leg from Michaud. Code 



Fig. 3 The ET Barge leaving Curtis Bay, Maryland. 


234 also coordinated with the U.S. Coast Guard to be 
sure that the Chesapeake bridges could be opened 
and that there would be no impediments to the travel of 
the barge up the Chesapeake. Even with this prior 
coordination and Coast Guard assurances, a contractor 



Fig. 4 The GRO Transporter being off loaded at KSC. 

painting a draw bridge left one of his barges tied on one 
side of the span, leaving insufficient room for the ET 
barge to pass safely. The ET barge, being 40 feet high 
and 200 feet long, acts as a sail in the wind and can be 
difficult to control in the narrow channels of the bay. 
Fortunately, the construction paint barge was removed 
without causing mishap to the ET barge and only 
minimally effecting the schedule. The positive aspect 
of the incident was that the U.S. Coast Guard was sure 
to have the way cleared for the actual shipment of the 
flight hardware. An assist tug also met the ET tug to 
help control and navigate the channels in the narrow 
confines of the upper Chesapeake and Curtis Bay. 

Curtis Bay . The Army Reserve (USAR) waterfront 
area at the Defense Logistics Agency (DLA) Depot at 
Curtis Bay, Maryland was the closest and most 
convenient harbor area to GSFC. Code 234 interfaced 
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with both the DLA and USAR to use their facilities. 
Unfortunately, the pier area at the bay was too old and 
weak to risk the weight of the container/transporter. 
Code 234 improvised by removing a section of the 
waterfront fencing and clearing an area of solid ground 
next to a sea wall to which the ET barge could tie up. 

Convoy from GSFC to Curtis Bay . Twenty-four 
hours prior to the scheduled departure, a last minute 
route survey was conducted to assure there were no 
new unknown hazards to the convoy. With only inches 
to spare in clearing some of the overpasses, a last 
minute road resurfacing raising the road level could 
have been disastrous. The survey vehicle, with its 
measuring pole, would act as the scout vehicle of the 
convoy leading it safely under the overpasses. On the 
evening before scheduled departure, the commercial 
tractors were inspected by Code 230 and hooked up to 
the transporters. The commercial and government 
escorts, support equipment truck, and porject vehicles 
formed up to await the arrival of the Maryland State 
Police escorts and the midnight departure time. At a 
little after midnight, the thirteen vehicle parade with 
amber hazard lights flashing departed for the 30 mile 
carefully routed trip to Curtis Bay - the beginning of the 
trip into space. 

Convoy Arrival at Curtis Bav & Barge Departure . 

The convoy arrived at Curtis Bay a little after the 
scheduled time of 0300, and the transporters were 
positiioned in the loading area for loading on the ET 
barge. The ET barge, having arrived the night before, 
was in position and ready to load. The loading of the 
transporters was accomplished as scheduled, the HST 
project passengers accompanying the shipment settled 
on board, and the barge crew cast off just after first light 
as planned, and headed out to the bay to begin the 
ocean journey to KSC. This time, as expected, the 
Coast Guard assured the way was clear with no 
obstacles. 

Arrival at Cape Canaveral . The ET barge arrived at 
Port Canaveral where the ocean-going deep water tug 
was replaced by a river pilot and two shallow water tugs 
that were capable of navigating the shallow waters of 
the Banana River to the ET dock at KSC. Code 234 
coordinated with KSC logistics personnel to assure the 
appropriate support vehicles and equipment was on 
hand to accomplish the off loading. The transporters 
were delivered to the appropriate processing facilities 
for their final preparation and integration and test 
before launch. 


The Mission 

The success of the HST First Servicing Mission made 
history and was witnessed by millions around the 
world. Every newspaper reported, in great detail, the 
servicing activities of the astronauts of the STS-61 
Space Shuttle Endeavour. All major "space logistics" 
objectives were accomplished; optics were installed 
that corrected the mirror's blurred images, ORU'swere 
installed to enhance the HST's reliability, and the 
feasibility and concepts of on-orbit servicing and repair 
in space were demonstrated and proven. And on 
earth, logisticians got the space flight hardware and the 
flight and ground support equipment to the launch pad 
- and then back home again. 

Post Mission Return of Mission Hardware to 
GSFC 

The logistics plan for the return of the hardware from 
KSC to GSFC was essentially the reverse of that for the 
trip to KSC, but, there were afew additional challenges. 
Original planning envisioned the return of the hardware 
to occur in the spring when the weather along the 
Atlantic Coast is more conducive to ocean travel. 
However, after the mission, the HST Project made the 
decision, based on cost and project requirements, to 
return the hardware to GSFC before the end of January 
1994. The logisticians of Code 230 scurried about to 
make it happen. Their coordination efforts were 
hampered by the Christmas holidays that fell between 
the time that the Endeavour and HST landed and the 
date the HST was requied at GSFC. A large number of 
government and contractor personnel involved and 
knowledgeable with the pre-launch shipment were on 
well deserved leave, basking in the success of the 
mission and enjoying the holidays. Many a phone call 
was answered with "sorry, they are on leave until the 
middle of January". Nonetheless, this "back-up" team 
coordinated and executed the effort to bring the 
hardware "back-up" to GSFC. Once again, the use of 
the ET barge was coordinated and scheduled to coincide 
with the delivery of an ET from Michaud to KSC. 
Everything went according to the plan except that 
which was beyond anyone's control, the weather. The 
barge was loaded to capacity with the HST container/ 
transporters, support equipment, an ACTS container 
destined for GSFC, and an ET cradle to be returned to 
Michaud. It departed the ET dock at KSC on schedule 
only to be delayed for a day at Port Canaveral by high 
seas and swells outside the port. After the barge left 
the port, the trip north was hampered by more of the 
bad weather for which the Atlantic winters are famous. 
After travelling north for a day, no headway was made 
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because high winds out of the north forced the barge to 
retrace its tracks. Off Cape Hatteras, swells over 20 
feet high buffeted the barge and cargo and caused 
discomfort to the passengers and crew, causing 
complexions to become pale and green. Meanwhile, 
the GSFC Washington DC/Baltimore area was 
experiencing one of its worst winters in decades - ice, 
sleet, snow, freezing temperatures. When the barge 
finally reached the mouth of the Chesapeake Bay, the 
water was calm - calmed by a covering of as much as 
4 inches of ice. The ice further slowed the progress of 
the barge. In the Curtis Bay where the channels are 
narrow, the water calm, the ice thickest, and the barge 
would be traveling its slowest, Code 230 called on the 
U.S. Coast Guard to break ice to enable the tugs to 
maneuver the barge to the dock more easily. Once at 
Curtis Bay, the awaiting escort vehicles, tractors, and 
support vehicles formed up with the transporters for 
their after-midnight convoy to GSFC and the final leg of 
the journey. 

Summary 

The on-orbit servicing of HST was a memorable logistics 


feat. Getting the hardware to the orbiting HST was a 
logistics feat in itself. The logistics journey of the HST 
hardware was over land, over water, and through air & 
space by truck, by barge, and by shuttle launch vehicle. 
The "earthy" logistics effort to support the HST First 
Servicing Mission involved the coordination and 
cooperation of government and contractor personnel 
from almost all the NASA Centers, HQ, GSFC, KSC & 
CCAFS, MSFC, LaRC; the GSFC Project Offices, 
HST/Code442, Logistics Management Division/Code 
230; the U.S. Army, U.S. Coast Guard, Defense 
Logistics Agency, and U.S. Air Force. The Hubble 
Space Telescope Logistics Team, proud of their 
contributions to the success of the HST First Servicing 
Mission, is looking forward to and have begun planning 
the logistics support for the HST Second Servicing 
Mission scheduled for early 1997. 
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ABSTRACT 

This paper provides an overview of computer 
simulation, the Lockheed developed STS Pro- 
cessing Model, and the application of computer 
simulation to a wide range of processes. The 
STS Processing Model is an icon driven model 
that uses commercial off the shelf software and 
a Macintosh personal computer. While it usu- 
ally takes one year to process and launch 8 space 
shuttles, with the STS Processing Model this 
process is computer simulated in about 5 min- 
utes. Facilities, orbiters, or ground support 
equipment can be added or deleted and the im- 
pact on launch rate, facility utilization, or other 
factors measured as desired. 

This same computer simulation technology can 
be used to simulate manufacturing, engineering, 
commercial, or business processes. The tech- 
nology does not require an “army” of software 
engineers to develop and operate, but instead 
can be used by the layman with only a minimal 
amount of training. Instead of making changes 
to a process and realizing the results after the 
fact, with computer simulation, changes can be 
made and processes perfected before they are 
implemented. 

Copyright © 1994 by Lockheed Space Operations Company. 
Published by the American Institute of Aeronautics and 
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COMPUTER SIMULATION OVERVIEW 

Computer simulation has traditionally been of- 
fered in two very different types of formats. 
Language-based simulation packages, such as 
SLAM and SIMAN, require the use of special- 
ized software languages and experts in simula- 
tion and coding in order to operate. The simu- 
lations performed by these language-based soft- 
ware packages tend to be very general in na- 
ture. On the other hand, data-driven simulators 
use pre-built graphical blocks to simulate com- 
mon processes found in areas such as manufac- 
turing. While effective for the domain for which 
they were intended, the pre-built graphical 
blocks are inflexible and cannot be used to simu- 
late other processes. 

With the advent of the Macintosh computer, and 
now Windows, and with the greatly increased 
power and affordability of these platforms, a 
third type of simulation software package has 
been developed. The hybrid simulation software 
package combines the power of the language- 
based packages with the ease of use of the 
graphical packages. The result is an easy to use, 
powerful, and flexible simulation package that 
can be used by the beginner, but also provides 
the means to develop customized blocks in or- 
der to produce very complex and intricate simu- 
lations by the experienced modeler. 
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STS PROCESSING MOOF.T . 

The processing of the Space Shuttle at Kennedy 
Space Center is performed mainly in three types 
of facilities. The Orbiter Processing Facility 
(OPF) is used to de-service and remove payload- 
unique equipment from the orbiter after a mis- 
sion, perform repairs and modifications, and 
install equipment and supplies in preparation for 
the next mission. The Vehicle Assembly Build- 
ing (VAB) is where the huge external tank (ET) 
is attached to the solid rocket boosters after they 
are stacked and is also where the orbiter is at- 
tached to the ET. The launch pad is used to pre- 
pare the vehicle for launch, including payload 
installation, fueling, and final checkout. Each 
of these facilities are limited in numbers; there 
are three OPF bays, two VAB bays, and two 
launch pads. The purpose of developing a STS 
Processing Model is to determine the impact 
upon the launch rate and facility utilization of 
events such as changes in the number of orbit- 


ers to process, facility shutdown, major flight 
part unavailability, or GSE disruptions. Other 
changes, such as the processing impact of a new 
launch vehicle upon the facilities and the ability 
of the launch site to effectively process both 
vehicles can also be modeled. Figure 1 presents 
an overview of the current STS processing re- 
quirements. 

The STS Processing Model was developed 
through the use of the simulation software Ex- 
tend + Manufacturing ™ available from Imag- 
ine That, Inc., San Jose, Ca. Extend is hybrid, 
library based, iconic-block (graphical element) 
commercial-off-the-shelf (COTS) simulation 
software package. The Model describes the be- 
havior of vehicles moving through the major 
processing facilities, to launch, mission and 
landing, and then back for processing. The 
Model operates in a discrete event mode, where 
events are orbiter movements or other status 
changes. Event times are driven by orbiter pro- 



Figure 1 . STS Processing Flow 
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Space Shuttle Processing Mode! 




Figure 2. STS Processing Model-Overview 


cess durations and the resolution of resource 
conflicts. An orbiter’s process duration is se- 
lected from a statistical distribution of achieved 
processing durations or a default constant. As 
can be seen in Figure 2, the simulation model of 
the launch site is very intuitive as the OPF, VAB, 
and launch pad footprints are used as part of the 
Model. The process flow on the screen is the 
same as the orbiter movement toward the launch 
pad. Additionally, icons of the shuttle, solid 
rocket boosters, and external tank provide vi- 
sual clues as to the status of the integrated flow. 

Through the use of an input screen, called the 
Notebook, assets such as orbiters or mobile 
launcher platforms (MLPs) can be added or de- 
leted in order to perform a “what-if ’ analysis. 
These type of changes take about 10 seconds to 
make, and it takes about 5 minutes to model a 
years worth of processing to determine the ef- 
fects on the launch site. Processing times that 
the Model pulls from the statistical database, 
such as for the OPF, VAB, or pads, are also 
shown in the notebook input screen (Figure 3) 
as the model is running. 

The output of the Model is shown in Figure 4. 
The output, which is a continuation of the Note- 
book, shows the achieved launch rate, yearly 
launch rate, facility utilization for each of the 
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Figure 3. STS Processing Model Notebooklnput Screen 
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facility processing bays and launch pads, and 
MLP and orbiter availability. A spreadsheet 
within the Notebook also captures the as-run data 
for each processing flow so that comparisons 
and statistical analyses can be made to deter- 
mine the results of each “what-if ’ ran. Addi- 
tional data elements can be added to the Note- 
book as desired. 

Each of the facilities represented consist of a 
hierarchical block. A hierarchical block is com- 
posed of a series of logic blocks that represent 
the logic and events that occur within the facil- 



ity. For instance, as shown in Figure 5, the pro- 
cessing flow within the VAB consists pf a series 
of library blocks that detail the logic of activi- 
ties that occur in the VAB. The stacking of the 
solid rocket boosters, mating of the external tank, 
and the integration of the shuttle with the stack 
are represented by a series of logic blocks. The 
statistics used to represent the durations of each 
event are taken directly from the actual times 
achieved from each of the processing flows since 
51-L, with the exception of the first flows for 
Back to Flight and unique flows due to hydro- 
gen leaks. 

Through the use of hierarchical blocks, it is very 
easy to add or delete facilities to determine the 
effect on the processing flow, launch rate, or 
facility utilization. After a hierarchical block is 
created, it can be added to a library, such as the 
STS Processing Library, and used to add the fa- 
cility in the processing flow as desired. It is 
also easy to delete a facility, simply by select- 
ing and deleting it, to determine the subsequent 
effect on the processing flow. Either change, 
whether adding or deleting a facility, takes less 
than 15 seconds to implement. 

Another type of “what-if’ analysis that can be 
done is to determine the effects upon facility 
utilization and launch rate if an OPF bay is shut- 
down for one year in order to perform extended 
duration modifications on an orbiter. As each 
of the bays and orbiters are the same as far as 
the model is concerned, OPF bay 3 is selected 
to have a one year period of downtime. The 
downtime is selected at a time when the orbiter 
is in the bay, in order to capture the orbiter for 
the downtime. A scheduled downtime block is 
added to the facility block in the OPF hierarchi- 
cal block and a downtime of one year is selected. 
After running the Model, it is determined that 
the launch rate decreases from 7 to 6 while the 
facility utilization of the remaining OPF facili- 
ties increases. A synopsis of the changes in- 
curred due to the addition of one year of OPF 
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Figure 5. VAB Hierarchical Block 


downtime is shown in Figure 6. 

Due to its nature as a hybrid simulation pack- 
age/language, Extend enables people with a wide 
range of ability to change the Model at many 
levels of detail. The user can double-click on 
block icons and change dialog parameters. From 
libraries supplied, the user can get new blocks, 
connect them, and enter parameters. For more 
flexibility, the user can enter formulae or equa- 
tions directly into an Equation block (Figure 7). 
The simpler groundrules are represented in 
Equation blocks, so the user can change these 
or add new blocks to modify groundrules. For 
the most flexibility, the user can create new 


primitive blocks by using Extend ' s built-in C 
compiler and dialog/icon editors to either modify 
a pre-existing block or build one from scratch. 
Most blocks needed are already pre-built. In 
fact, all but one of the blocks used to build the 
Model are pre-built. 

MODELING processes 

The simulation software and techniques used to 
develop the STS Processing Model can also be 
applied to a wide range of processes, such as 
manufacturing, engineering, and business pro- 
cess reengineering. Specific models may in- 


24 


American Institute of Aeronautics and Astronautics 



Measurement 

Normal 

Operations 

With 

Downtime 

Number of 
Launches 

7 

6 

OPF Bay 1 
Utilization 

86.6% 

93.9% 

OPF Bay 2 
Utilization 

66.0% 

74.1% 

OPF Bay 3 
Utilization 

85.9% 

0% 

Number of Orbiters 
on Pad 

(Ready for launch) 

2 

0 


Figure 6. Effect of OPF Bay 3 Downtime for One Year 
on the Launch Rate and OPF Utilization 


elude logistics inventory analyses, electronic 
circuit development, or paperwork flow im- 
provement. The software is designed to be used 
by the layman, and therefore does not require 
the services of software or modeling experts in 
order to use. 

By modeling processes, a manager shifts the 
focus from dealing with outcomes to managing 
the means for achieving customer and business 
value. Aspects a manager often deals with, such 
as excess inventory, overtime, expediting, safety 
problems, worker morale, or delivery perfor- 
mance, are often the cause of the nature of the 
overall system. However, when identifying a 
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Figure 7. Equation Block Dialog 


specific item to change in the system, it is diffi- 
cult to perceive the overall effect due to the syn- 
ergy which occurs when all relationships act 
together. Flow charts can help identify the sys- 
tem parts and process sequence, and spread- 
sheets can help calculate some mathematical 
relationships, but the overall cause-and-effect 
relationships are hard to capture with such tools. 
A simulation model effectively mimics the dy- 
namic behavior of a flow system, where real- 
world elements interact when specific events 
occur, and where behavior may be driven by 
probabilistic processes and feedback. 

Another benefit of simulation is the ability to 
build or change a process on a computer before 
it is actually implemented. The building of a 
simulation model requires that a consensus be 
developed among the interested parties on what 
is actually required, which often changes and 
aligns the perceptions of the parties involved. 
Based upon up-front understanding of the pro- 
cess and mutually agreed to changes, this "con- 
sensual reality" often leads to an improved pro- 
cess when implemented. 


CONCLUSION 

With the introduction of ever more powerful 
personal computers and easy to use simulation 
software such as Extend, computer simulation 
is a now a readily available tool. The STS Pro- 
cessing Model is an example of a fast and flex- 
ible tool for the evaluation of shuttle processing 
scenarios by personnel not familiar with simu- 
lation modeling or techniques. In addition, simu- 
lation can be used on a wide range of processes 
to model new developments or changes to ex- 
isting systems to determine the effectiveness of 
the processes before they are implemented. 
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Abstract 


The process to predict the values of the 
maintenance time dependent variable parameters 
such as MTBF over time must be one that will not (2) 
in turn introduce uncontrolled deviation in the 
results of the ILS analysis such as Life Cycle Cost, 
spares calculation, etc. A minor deviation in the (3) 
values of the maintenance time dependent variable 
parameters such as MTBF over time will have a 
significant impact on the logistics resources 
demands, International Space Station Availability 
and maintenance support costs. It is the objective (4) 
of this report to identify the magnitude of the 
expected enhancement in the accuracy of the 
results for the International Space Station Reliability 
and Maintainability data packages by providing 1. 
examples. These examples partially portray the 
necessary information by evaluating the impact of 
the said enhancements on the Life Cycle Cost and 
the Availability of the International Space Station. 

The examples are as follows: 

(1) The Non Electronic reliability data hand 
book (NPRD) usage by the program 

RAM data packages (i.e. a vague 
approximation of pails count) vs. the actual 


stress method of prediction; 

Constant failure rate prediction vs. what 
distribution it should be; 

Percentage of the parts on the International 
Space Station with constant failure rates in 
relation to the overall International Space 
Station configuration, 

Miscellaneous enhancements that can 
benefit the overall program RAM data 
packages. 

R EFER ENCES 

A. CSA SOW dated December 1993; 

B. Space Station Freedom External 
Maintenance Task Team, July 
1990, final report; 

C. External Maintenance Solution 
Team, January 1991, final report. 

D. SPAR-SS-SASD-0265, Back up 
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drive unit MTBF prediction, March 
03 1993; 

E. 

SPAR-SS-R-0482, Limited Life 
Items List for MSS, May 1993; 

F. 

SPAR-SS-SASD-0260, Joint 
backup relay unitpreliminary MTBF 
prediction, March 03 1993; 

G. 

S PAR- SS-SASD -0259, LEE 
backup relay unit preliminary 
MTBF prediction, March 03 1993; 

H. 

SPAR-SS-SASD-01 1 5, Joint 
electronic unit MTBF prediction, 
Oct 27 1 993; 

1. 

SPAR-SS-R-061 3, Orbit 
replaceable unit (ORU) list for 
MSS, May 1993; 

J. 

Applications of Space Logistics 
Engineering in Quantitative Risks 
assessment and management of 
Space Station Freedom, AIAA 
1991, Cocoa Beach, Florida, F. 
Sepehry-Fard. 

K. 

Reliability worksheet on the 
SSRMS joints, dated May, 28, 
1993. 

2. 

OBJECTIVE 

2.1 The objective of this report is to note the 

factors (environmental, pre-operational, 
others) which must be taken into account 
during the process of accurately predicting 
the maintenance time dependent variables 
in a space environment; to indicate the 


potential delta if the real failure rate 
parameters are not used for such models 
as life cycle costs and availability; and to 
recommend actions to enhance the 
program RAM packages by achieving a 
more thorough accounting for all 
anticipated factors. 


3 I NTRO DUCTION 

3.1 In response to Reference A task, a series 
of three (3) reports which describes the 
initial approach to conduct refinement 
processes for the maintenance time 
dependent parameters such as MTBF in 
order to accurately forecast the Logistics 
Support requirements shall be submitted. 
This is the third report of the three reports. 
The paramount and complex problem 
relative to the time dependent 
maintenance variable parameters became 
apparent as a result of the investigations 
performed on the program's RAM 
packages. Find attached as Annex A, a 
description of the cost delta between the 
Weibull and exponential failure density 
distribution on the SSRMS joint. 

3.2 This report includes examples to indicate 
the potential delta if the real failure rate 
parameters are not used in subsequent 
resource modelling activities. These 
examples partially portray the necessary 
information by evaluating the impact of the 
said deficiencies on the Life Cycle Cost 
and the Availability of the MSS. The 
examples are as follows: 

3.2.1 The Non Electronic reliability data 
hand book (NPRD) usage by the 
RAM data packages (i.e. a vague 
approximation of parts count) vs. 
the actual stress method of 
prediction; 

3.2.2 Constant failure rate prediction vs 
what distribution it should be; 

3.2.3 Percentage of the parts on the 
MSS with constant failure rate in 
relation to the overall MSS 
configuration; 

3.2.4 Miscellaneous deviations inherent 
in the RAM data packages. 

3.3 The NPRD reliability assessment of the 
ORUs vs. actual stress method prediction 

3.3.1 Ref. E states that the failure rates 
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were obtained using the NPRD. 
Let us examine this way of 
assessment and evaluate the 
impact on (lie logistics support 
requirements. Examination of 
reliability worksheets performed by 
Ref. K dated 28, May 1993, 
elucidates explicitly that all the 
joints are treated the same generic 
way. In other words, all the joints 
are assumed to have the same 
MTBF figure and the assessment 
of the failure rate utilizes the 
NPRD-91 . In view of the fact that 
different joints on the MSS go 
through different stress levels and 
furthermore there is not any layout 
and/or schematics in the NPRD-91 
in order to justify this analysis and 
similiarization. This universal 
treatment of the joints can be 
extremely off with respect to the 
prediction of the time dependent 
maintenance parameters such as 
MTBF, MDT, etc which directly 
affect and are the key drivers for 
the accurate forecast of 
operational and steady state 
availability, spares and support 
equipment requirements. The 
following examples illustrate these 
deviations. 

34 Percentages of Electronic/Electrical, 

Electromechanical, Mechanical, Structural 

Mechanical and Structural parts on the 

MSS. 

34 1 The following illustrate the 
percentages of Electronic/ 
Electrical, Electromechanical, 
Mechanical, Structural Mechanical 
and Structural parts on the MSS. 
According to Ref. I and B, there 
are 83 and 213 CSA ORUs, 
respectively. Our analysis utilizes 
the number provided in Ref. I and 
categorizes the ORUs in 5 different 
classes. 7 his analysis is based on 
engineering judgement and 
approximation on the percentages 
of the parts count embodied in 


each ORU. This assessment 
assumes that the failure and repair 
distributions allocated for different 
family of products (i.e. Electrical, 
Mechanical, etc.) will not be 
changed as a result of exposures 
to Solar Flares, Atomic Oxygen, 
Micrometeorite, etc. 

The different family of products 
percentages on the MSS are as 
follows: 

27% of failures related to 
Electromechanical parts, 19% of 
failures related to mechanical 
parts, 3% of failures related to 
Structural mechanical parts, 27% 
of failures related to Structural 
parts belong to other distributions 
than exponential such as Normal, 
Lognormal, Gamma, Weibull, etc. 
which should be assessed 
according to the methodologies 
explained in this report. 

3.4.2 Report 2 states that exponential 
failure distribution to predict MTBF 
is almost exclusively used for 
electronic equipment. Exponential 
failure distribution describes the 
situation wherein the hazard rate is 
constant which can be shown to 
be generated by a Poisson 
process. Some particular 
applications of this model include: 

A. Items whose failure rates 
do not change significantly 
with age; 

B. Complex and repairable 
equipment without 
excessive amounts of 
redundancy; 

C. Equipment for which the 
early failures or "infant 
mortalities" have been 
eliminated by "burning in" 
the equipment for some 
reasonable time period. 
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3.4.3 Only about 24% (i.e. Electronic/ C. 
Electrical family of products on the 
MSS) of these assessments D. 

belong to exponential failure 
distribution. Depending on the 
value of |1, the weibull distribution E. 

function can take the form of the 
following distributions as follows: F. 

^ < 1 Gamma 1 

i = 1 Exponential 

i = 2 Lognormal 0 

i = 3.5 Normal 2 

(approximately) 

3 

Thus, it may be used to help 

identify other distributions from the 
life test data or other data from the 
previous spacecraft anomalies 
(backed up by goodness of fit 
tests, see recommendation) as 
well as being a distribution in its 
own right. In order to determine 
the distribution densities for the 
different family of products, we 
have to look at the reliability and 
life tests data backed up by other 
actual data which best represent 
the real life scenario of the 

products in question. These 
assignments of failure density 
distributions can, as 
recommendation suggests, be 
verified and validated by means of 
goodness of fitness tests. 

3.5 The following calculation 
demonstrates the potential delta in 
what is being proposed vs what it 
should be as far the cost of the 
impact on the Life Cycle Cost and 
Availability of the MSS are 
concerned. The assumptions for 
calculating these figures and the 
subsequent items A - F are 
provided accordingly: 

A. It is intended to benefit the MSS program 
by $5 Billion over 30 years (Ref. J); 

B. Initial Acquisition cost' 1.2 Billion 


CSA’s predicted MTBF 2 242,752 Hours 

Recalculated MTBF using NPRD3 329.47 
Hours 

Total down time 4 25 Hours 
Total corrective maintenance time 5 5 Hours 
See Ref. J. 

See Ref. K. 

This calculation utilizes NPRD-91 . NPRD 
uses a constant failure rate model for 
generic failure rate predictions. This 

calculation does not in any way represent 
the real case scenario rather it is intended 
to show the possible swing in NPRD values 
using different justifications and 

approximations (MSS Reliability 
Worksheets, Ref. K, uses the Ground fixed 
as the environment. Based on the same 
kind of justifications and approximations, 
utilization of Ground Mobile environment 
can also be substantiated). Please also 
see Annex A. 

MTTR = 5 hours (Ref. J), Assume 
overhead of 500% therefore: 

Total Down Time 5 Hours x 5 = 25 Hours 

5 MTTR of Joint Drive Module = 5 Hours 
(Ref. J) 

Total Corrective Maintenance Time = 5 Hours 

3 5.1 It is quite clear, from the above, 
that the steady state Availability 
will be affected as a result of 
tremendous inaccuracy inherent in 
the method of calculation and the 
results of the CSA’s time 
dependent maintenance parameter 
prediction such as MTBF, MDT, 
etc. 


A ( t) - a - 

* MTBF i MTTR 
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A. It is evident from the above, that 
uncontrolled deviation in the MTBF 
and MDT values would mean 
totally inaccurate results for the 
Availability. This means that 
effective planning related to the 
assembly, operation and utilization 
of the SSRMS, MSS and/or the 
International Space Station can not 
be performed; 

B. Furthermore, the opportunity costs, 
needless delay in schedule, costs 
due to unavailability or surplus of 
the support equipment, as result of 
the above, are expected; 

C. As an example, the cost of launch 
per lbs is $5000. Each joint is 252 
lbs and the price of each joint is 
more than $4 Million. The 
inaccuracy of the time dependent 
maintenance parameters (i.e. 
MTBF, MDT. etc.) values means 
inability to accurately predict the 
occurrence of the failures (random 
and wear out) as a function of 
time. This means that adequate 
logistics resources may not be 
available at the right time. This 
fudhermore means that there may 
be an operational impact due to 
insufficient support resources. 

3 6 The Miscellaneous deviations inherent in 
the RAM data packages include but are not 
limited to the following: 

36.1 Ref. H, in section 4.0, refers to 
microcircuit failure rates based on 
junction temperatures of 55 C. 
Examination of the parts 
breakdown of the same document 
in its 1C section clearly indicates 
that a good portion of the 1C s 
used are CMOS. CMOS 
technology utilizes the channel not 
junction. Junction terminology is 
merely used for bipolar products 
which are, in view of their high 
power consumption vs the CMOS, 


not looked at very favourably. 
Furthermore, it is understood that 
the Russians are capable of repair 
and removal of their ORUs at the 
component level, and that the 
ISSA program may be pursuing 
methods of increasing in-situ 
maintenance and intermediate 
maintenance on-orbit. It is 
therefore necessary for us to 
understand the physics of the 
components used on the MSS to 
preclude unnecessary delay and 
support costs from an effective 
logistics support requirements 
program plan for the MSS. 

3 6.2 Examination of Ref. F. elucidates 
explicitly that the MTBF obtained, 
based on parts count prediction, 
for the Joint Backup Relay Unit 
(LBRU) is 37,907,506 hours this 
translates to over 4000 years. It 
has been the author’s experience, 
during the FMECA on the 
SARSAT, that based on some 
failure modes (such as shorting the 
DC capacitors) the following 

failures may occur on the MSS: 

a. Drainage of the solar 
power system without the 
ability to detect the failure 
mentioned above (the 
redundant fuses rating, if 
any, may be between the 
threshold value and its 
blowing value based on 
this failure mode) and/or; 

b. Relay contacts sticking 
due to continuous over 
current flow. 

3.6.3 Examination of Ref. E. shows that 
the criteria for life Limiting Items 
are based on linear relationships 
(i.e. Table 2-1 -1-1 , 13 years 

mentioned for SSRMS joints based 
on initial 35 years of Space 
Station operation). As it has 
clearly been stated in report 1 , 2 
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and backed up an by example in 
this report, this assumption and/or 
observation is not valid. Each of 
the ORUs and their subsystems 
should be assigned a failure and 
repair density function. The 
predictions for LLI (Life Limited 
Items) should only then performed 
from the above-mentioned 
distributions. 


4. RECOMMEN DAT ION 

In view of the aforementioned deviations, it 
is highly recommended that the following 
tasks be performed: 

4.1 Case studies in relation to the 
different failure and repair 
distribution density functions in 
order to determine, quantify and 
timeline the Logistics Support and 
spares requirements for the MSS, 
etc; 

4.2 Verification and validation on the 
maintenance time dependent 
parameters such as MTBF and 
MDT using statistical tests such as 
D test, chi square test, goodness 
of fitness tests in order to validate 
and verify the distributions 
assigned to different family of 
products, etc; 

4.3 The following areas need also be 
addressed in order to incur an 
accurate logistics support 
requirements: 

a. Common mode failures; 

b. Common cause failures; 

c. Maintenance/Operations 
induced failures; 

d. Life limited items; 

e. Duty cycle (i.e. duty cycle 
does not necessarily 
increase failure rates) 

f. Construction induced 
failures; 

g. Advances in technology; 


h. Mid Life Update (MLU) of 
the MSS. 

4.4 MSS and SSRMS Probability of 
survival, operational and steady 
state availability assessment based 
on different mission criticality 
scenarios; 

4.5 Research in frequency of 
occurrence of cosmic rays, 
Micrometeorite, flares, atomic 
oxygen, magnetic storms, etc. in 
order to quantify and substantiate 
their impact on the Life Cycle cost 
and Logistics support requirements 
of the MSS; 

4.6 Determination of time truncated 
and failure truncated events for 
planning the required logistics 
resources; 

4.7 Determination and level of space 
insurance based on quantitative 
risks assessment and 
management of the MSS and 
SSRMS; 

4.8 Research in order to determine the 
effects of the combined 
environments, i.e. cosmic rays and 
micrometeorite, in order to 
accurately determine and quantify 
the Logistics Support and spares 
requirements, etc; 

4.9 Spacecraft anomalies data base 
set up in order to exploit the space 
industry failure and repair historical 
data (i.e. MIR) to be able to 
baseline the time 
dependentmaintenance parameters 
accordingly; 

4.10 In order to accurately forecast the 
resource demands as a function of 
time during the operation phase, it 
is vital to accurately assess the 
following with the amalgamation of 
the space stringent requirements 
such as flares, cosmic rays, 
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micrometeorite, etc. These 
amalgamation should quantify the 
impact of the said parameters, 
either by themselves or combined, 
on the following areas of 
investigations: 


A. 

FMECA; 

B. 

Parts Application Review; 

C. 

Single Point failures 

D. 

Life Limited Items List; 

E. 

Safety and Hazard 


analysis; and 

F. 

Reliability Predictions. 


These assessments are in part due to the 
possible marriage overtones among the 
different ORU functionalities, etc. 


ANNEX A: The cost delta between the weibull 

and exponential failure density 
distribution on the SSRMS joint 


1. The usefulness of the models based on 
constant failure rates is limited because they do not 
adequately account for the fact most mechanical 
products have a failure rate which is not constant 
with time as shown in figure 1 . 



Figure 1 : Typical Hazard plots for Electronic 

and Mechanical components 


The problem that we face in trying to use the 
exponential (i.e. MiLHDBK-217, etc ) prediction 
model for mechanical components is that there is 
no "useful life" period in which the failure rate is 
approximately constant with time. We have a 
situation as shown in figure 2. The constant failure 
rate only corresponds to the actual failure rate at a 
specific time which is unknown. 



Figure 2: Comparison of Prediction and Actual 

Failure Rate. 

By using the Weibull distribution to represent the 
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RAM data for the mechanical parts such as the a. 
joints on the SSRMS, the non constant failure rate 
can be dealt with. The equations for the reliability 
function and failure rate function for the Weibull b. 
distribution are shown in report 2. The Reliability (t 
= n) = e 1 = 0.368, the failed population = 63.2% 
and X (t = n) = ()/n. It can be seen from the last 
equation that at a time equal to the Weibull 
characteristics life, the failure rate function 
simplifies to being equal to the Weibull slope 
divided by the characteristics life. If we modify the 
“MIL-HDBK-217 Type" prediction model to predict 
the failure rate at a time equal to the Weibull 
characteristics Life we have the condition shown in 
figure 3. This modification can be accomplished by 
adjusting the base failure rate in order to obtain 
agreement between the proposed prediction model c. 
and the more accurate model based on Weibull 
failure density function. In order to accomplish this 
modification, it is necessary to accurately determine 
the Weibull probability parameters from different 
sources of data (i.e. reliability and space 
qualification testing, field experience, etc). By 
plotting the failures based on Weibull failure density 
distribution on a Weibull probability paper, we 
should see the indication of a convex shape which 
is very likely due to the effect of infant mortality 
failures. The shape of the these kinds of plot 
suggests that it could reasonably be fitted by the 
mixture of two distributions. The RMAT default 
value for the |i is 5. Based on the current situation, 
we assign two sets of p values namely 3 and 5. 

We will evaluate the delta of what is being 
proposed based on constant failure rates and its 
impact on the overall logistics support cost for the j 
joints of the SSRMS. The following assumption 
have been made: 



Figure 3: Prediction Equals Actual Failure 

Rate At Weibull Characteristics Life 


SPAR MTBF for the joint is accurate and is 
242,752 hours; 

All the parts in the joint resemble a Weibull 
failure density distribution (i.e. even though 
there are some electrical/electronic 
components on the joint, they are also 
assumed to follow a Weibull failure density 
functions). In real life, it is customary to 
categorize the different family of products 
according to their respective failure and 
repair density functions and obtain the 
cumulative probability of survival and 
failure in order to come up with much more 
accurate results); 

For Weibull distribution: 

X (t=n) = p/n 
X = 3/242,752 

X = 12.35 failures E-6 Hours 


or: 

for p = 5 
X = 5/242752 

X = 20 6 failures E -6 Hours 


For exponential distribution: 
X = 4.2 failures E -6 Hours 


The deita (ratio) for the two Weibull failure 
density distribution cases (i.e. p = 3 and p 
= 5) and the exponential failure density 
distribution with constant failure rate are 
290% and 490%, respectively. 

The following table illustrates the 
unnecessary cost due to these types of 
inaccurate maintenance time dependent 
parameters prediction: 



MSPAR) 


X <(1=3) 


MM) 


RATIO RATIO Ps 


P, 


(P=3/e) (p=5/e) 


4.12 12.35 20.6 290% 490% 36.8% 63.2% 

F/10E6HRS F/10E6HRS F/10E6HRS 


These values represent the best case 
scenario. In other words, they only 
represent the delta between the 
assessment of constant failure rate vs. non 
constant failure density distribution (i.e. the 
Weibull distribution). In reality, if we were 
to include all the other RAM data 
deviations (i.e. Orbital debris, Cosmic 
Rays, etc ), the level of the ineffectiveness 
of the current Logistics Support 
Requirements would have been much 
more pronounced. 
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The process to predict the values of the 
maintenance time dependent variable parameters 
such as MTBF over time must be one that will 
not in turn introduce uncontrolled deviation in the 
results of the ILS analysis such as Life Cycle 
Cost, spares calculation, etc. A minor deviation 
in the values of the maintenance time dependent 
variable parameters such as MTBF over time will 
have a significant impact on the logistics 
resources demands, International Space Station 
Availability and maintenance support costs. 
There are two types of parameters in the logistics 
and maintenance world: 

a. Fixed; 

b. Variable 

Fixed parameters, such as cost per man hour, is 
relatively easy to predict and forecast. These 
parameters normally follow a linear path and they 
do not change randomly. As an example, if the 
cost per man hour in 1993 is $76, this rate will 
amount to $78.28 per hour for 1994 considering 
the inflation rate of 3% per annum. However, 
the variable parameters subject to the study in 
this report such as 

MTBF do not follow a linear path and they 


normally fall within the distribution curves which 
are discussed in this publication. The very 
challenging task then becomes the utilization of 
statistical techniques, as illustrated in this report, 
to be able to accurately forecast the future non 
linear time dependent variable arisings and 
events with a high confidence level. This, in turn, 
shall translate in tremendous cost savings and 
improved availability all around. 

1 R EFERENCES 

A. Space Station Freedom External 
Maintenance Task Team, July 
1990, final report; 

B. External Maintenance Solution 
Team, January 1991, final 
report. 


2 . INTRODUCTION 

2.1 A series of three (3) reports which 

describes the initial approach to conduct 
refinement processes for the maintenance time 
dependent parameters such as MTBF in order to 
accurately forecast the Logistics Support 
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requirements were completed. This is the 
second of the three reports. The paramount and 
complex problem relative to the time dependent 
maintenance variable parameters became 
apparent as a result of the investigations on the 
programs’s RAM packages. 

2.2 The process to predict the values of the 
maintenance time dependent variable parameters 
such as MTBF over time, as report 1 (this report 
is labelled as "INTEGRATED LOGISTICS 
SUPPORT ANALYSIS OF THE INTERNATIONAL 
SPACE STATION, AN OVERVIEW OF THE 
MAINTENANCE TIME DEPENDENT 
PARAMETER PREDICTION METHODS 
ENHANCEMENT" and is published in this 
symposium) and annex A of this report elucidate, 
can not be treated by the same process as the 
program's data packages suggest as this will 
introduce uncontrolled deviation in the results of 
the ILS analysis such as Life Cycle Cost, spares 
calculation, etc. Furthermore, the very acute 
problems ofmicrometeroites, Cosmic rays, flares, 
atornicoxygen, ionization effects, orbital plumes 
and all the other factors that differentiate 
maintainable space operations from non 
maintainable space operations and/or ground 
operations must be accounted for by the 
program’s RAM data packages. Therefore, these 
parameters need be subjected to a special and 
complex process. 

2.3 FSF, per the direction of CSA 
management, elected to investigate these 
parameters due to the complexity of the process 
involved and because these parameters' values 
and data packages have shown not to have a 
common denominator as far as the method of 
assessment and calculation are concerned; a 
minor deviation in their values will have a 
significant impact on the logistics resources 
demands, MSS availability and maintenance 
support costs. 

2.4 There are two types of parameters in the 
logistics and maintenance world: 

A. Fixed; 

B. Variable 

2.5 Fixed parameters, such as cost per man 


hour, is relatively easy to predict and forecast. 
These parameters normally follow a linear path 
and they do not change randomly. As an 
example, if the cost per man hour in 1 993 is $76, 
this rate will amount to $78.28 per hour 
considering the inflation rate of 3% per annum. 
However, the variable parameters subject to the 
study in this report such as MTBF do not follow 
a linear path that they normally fall within the 
distribution curves discussed in annex A. 

2.6 The very challenging task then becomes 

the utilization of statistical techniques, as 

illustrated in this report, to be able to accurately 
forecast the future non linear time dependent 
variable arisings and events with a high 
confidence level. This, in turn, shall translate in 
tremendous cost savings and improved 
availability all around. 

2.7 The objectives of this report are two fold: 

A. To explain the requirements for 
accurate prediction of different 
structural, mechanical and 
electrical ORU’s time dependent 
maintenance parameters such 
as MTBF; and 

B. Describe, in general terms, the 
steps required (including a 
mathematical background) to 
predict the MTBF values over 
time in order to increase 
accuracy of the results pertaining 
to the MSS spares modelling & 
calculation, availability, Life 
Cycle Cost, etc. 

3. REQUIREMENTS FOR PREDICT ING 

MTBF VALUE AS FUNCTION OF TIME 

3.1 The random predicted value and the 
actual value fluctuations for time dependent 
maintenance parameters such as mean time 
between failures (MTBF) and mean down time 
(MDT) which are the key drivers for effective 
logistics support planning, proved to be stumbling 
blocks in providing the accurate and necessary 
logistics support requirements. This deficiency is 
due to the fact (Ref. annex A) that structural, 
mechanical and electrical family of products 
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belong to different distribution functions. There is 
at present no single method available to 
accurately predict these future arisings and their 
frequency and effectively estimate logistics 
support requirements for the MSS. 

3.2 The necessary mathematical background 
that the reader has to become familiar 
with is provided in annex A. 

3.3 Figure 3.3.1 shows the flow diagram 
explaining the top level steps necessary 
to refine the time dependent 
maintenance parameters such as MTBF. 



REFINEMENT PROCESS FOR THE TIME 
DEPENDENT MAINTENANCE PARAMETER 


FIGURE 3.3.1 










ANNEX A 


STATISTICAL DISTRIBUTION TYPES 


1 . There are many standard statistical 
distributions which may be used to model the 
various maintenance time dependent variable 
parameters such as MTBF (Mean Time Between 
Failures) and MDT (Mean Down Time). The 
particular distribution used depends upon the 
nature of the data, in each case. Following is a 
short summary of some of the distributions most 
commonly used in statistical analysis and the 
criteria for their use. The distributions can be 
categorized in two criteria: 

A. Continuous distributions; and 

B. Discrete distributions. 


CONTINUOUS DISTRIBUTIONS 


analysis of manufactured items and their ability to 
meet specifications. No two parts made to the 
same specification are exactly alike. The 
variability of parts leads to a variability in systems 
composed of those parts. The design must take 
this part variability into account, otherwise the 
system may not meet the specifications 
requirement due to the combined effect of part 
variability. Another aspect of this application is in 
quality control procedures. The basis for the use 
of normal distribution in this application is the 
central limit theorem which states that the sum of 
a large number of identically distributed random 
variables, each with finite mean and variance, is 
normally distributed. Thus, the variations in value 
of electronic component parts, for example, due 
to manufacturing are considered normally 
distributed. 


1.1 Continuous distributions, as the name 
implies, are distributions with continuous shape 
and form. They primarily consist of the following 
distributions: 


Normal distribution 


1-1-1 There are two principal 

applications of the normal distribution to statistical 
analysis. One application deals with the analysis 
of items which exhibit failure due to wear, such 
as mechanical devices. Frequently the wear out 
failure distribution is sufficiently close to normal 
and that the use of this distribution for predicting 
or assessing maintenance time dependent 
variable parameters, after preliminary 
assessments, can be shown to be valid. 


1.1.3 The failure density function for the normal 
distribution is 


fit) = _ exp 

O (271) 2 




2 


Where: 


U = The population mean 

o = The population standard 
deviation, which is the V of the variance. 


1.1.2 The other application deals with the 



39 


Lognormal distribution 

1.1.4 The lognormal distribution is the distribution of a random variable whose natural logarithm is 
distributed normally; in other words, it is the normal distribution with In t as the variable. The density 
function is: 


fit) = exp 

O t (2tt) 2 

for t > 0 

Where the mean = 




the standard deviation - [ ex p ( 2 u ♦ 2o 2 ) - exp ( 2 ,J ♦ o 2 ) ] * 

and where u and o are the mean and the standard deviation of In t. 


1.1.5 The lognormal distribution is used in 
statistical analysis of semiconductors and fatigue 
life of certain types of mechanical components. 
Its main application is really in maintainability 
analysis of time to repair data. 


Exponential distribution 

1.1.6 This is probably one of the most 
important distributions in statistical analysis and 
is almost exclusively for statistical analysis of 
electronic equipment. It describes the situation 
wherein the hazard rate is constant which can be 
shown to be generated by a Poisson process. 
This distribution is valuable if properly used. It 
has the advantages of: 


A. Single, easily estimated 
parameter (X)] 


B. Mathematically very tractable; 

C. fairly wide applicability; 

D. is additive - that is, the sum of a 
number of independent; 
exponentially distributed 
variables is exponentially 
distributed. 

1.1.7 Some particular application of this model 
include: 

A. Items whose failure rates do not 
change significantly with age; 

B. Complex and repairable 
equipment without excessive 
amounts of redundancy; 

C. Equipment for which the early 
failures or "infant mortalities" 
have been eliminated by 
"burning in" the equipment for 
some reasonable time period. 

1.1.8 The failure density function is 
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f(t) = Ae‘ At 


Ha) = f x al e~ x dx . 

Jo 


for t>0, where A is the hazard (failure) rate and 
the reliability function is: 


R(t) = e~ Xc 


the mean life (0)= 1/A, and, for repairable 
equipment, the MTBF = (0) = 1/A.. 

Gamma distribution 

1.1.9 The gamma distribution is used in 
statistical analysis for cases where partial failures 
can exist, i.e., when a given number of partial 
failures must occur before an item fails (e.g, 
redundant systems) or the time to second failure 
when the time to failure is exponentially 
distributed. The failure density function is: 

fU) = rrrV at )-' 1 e~ Xt 

r(a) 


which can be evaluated by means of standard 
tables. Where (<x-1) is a positive integer, 
T(cx)=(ot-1 )!, which is usually the case for most 
statistical analysis, e.g, partial failure situation. 
For this case the failure density function is: 


tU) = T^OT e U 


which, for the case of a=1 becomes the 
exponential density function, previously 
described. The gamma distribution can also be 
used to describe an increasing or decreasing 
hazard (failure) rate. When a>1, h(t) increases; 
when a<1 , h(t) decreases. 


for t > 0 
where u = -¥- 

At 


1 



Where X is the failure rate (complete failure) and 

a the number of partial failures for complete 
failure or events to generate a failure. V(a) is the 
gamma function 
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Weibull disUjbution 

1 i 10 The Weibull distribution is particularly useful in statistical analysis since it is a general distribution 
which by adjustment of the distribution parameters, can be made to model a wide range of life distribution 
characteristics of different classes of engineered items. One of the versions of the failure density function 

is: 


fit) 


= I 

n 


1 exp 

1 

CT 

-< 

l T) / 

\ M / J 


Where: ft is the shape parameter n is the scale parameter or characteristic life (life at which 63.2 k of the 
population will have failed)y is the minimum life 


1.1.11 In most practical statistical analysis 
situations, y is often zero (failure assumed to start 
at t = 0) and the failure density function becomes 



and the reliability and hazard functions become 
Rit) =exp[-(^)'‘] 



DISCRETE DISTRIBUTIONS 

1.2 Discrete distributions, as the name 
implies, are distributions with non-continuous 
shape and form. They primarily consist of the 
following distributions: 


Bino rpjal distributio n 


1.2.1 The Binomial distribution is used for 
those situations in which there are only two 
outcomes, such as success or failure, and the 
probability remains the same for all trials. It is 
very useful in statistical analysis and quality 
assurance work. The probability density function 
(PDF) of the binomial distribution is: 

«-(;) pv m 




and q = 1 -p 


f(x) is the probability of obtaining exactly x good 
items and (n-x) bad items in a sample of n items 
where p is the probability of obtaining a good 
item (success) and q (or 1 -p) is the probability of 
obtaining a bad item (failure). 

1.2.2 The cumulative distribution function 
(CDF), i.e., the probability of obtaining r or fewer 
successes in n trials, is given by 
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F{x.i) = 

x*0 V XJ 


RM 


_ o- 

0 ! 


POISSON DISTRIBUTION 

1.2.3 This distribution is used quite frequently 
in statistical analysis. It can be considered an 
extension of the binomial distribution when n > 20 
and p < 0.05. 

If events are Poisson distributed, they occur at a 
constant average rate and the number of events 
occurring in any time interval are independent of 
the number of events occurring in any other time 
interval. For example, the number of failures in 
a given time would be given by: 




a x e a 


xi 


where x is the number of failures and a is the 
expected number of a failures. For the purpose 
of statistical analysis, this becomes: 


Kk k, o = 


(xtfe- u 

x! 


or our old friend the exponential distribution. 

1 .2.4 In the case of redundant equipments, the 
R(t) might be desired in terms of the probability 
of r or fewer failures in time t. For that case: 


flW -E 


x=o 


x! 


1.2.5 Figure 1.1 illustrate the density function, 
reliability function and hazard rate for the normal, 
Exponential, Gamma, Weibull and Lognormal 
distributions. 

1.2.6 Figure 1.2 shows the shapes of failure 
density and reliability functions of commonly 
used discrete distributions. 


Where: 

X = failure rate 

t = length of time being considered 
x = number of failures 

The reliability function, R(t), or the probability of 
zero failures in time t is given by: 
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Abstract 


significantly increasing the risk of unsatisfied 
demand. 


The NASA Shuttle Logistics Depot (NSLD) is 
tasked with the responsibility for repair and 
manufacture of Line Replaceable Unit (LRU) 
hardware and components to support the Space 
Shuttle Orbiter. Due to shrinking budgets, cost 
effective repair of LRUs becomes a primary 
objective. To achieve this objective, it is 
imperative that resources can be assigned to 
those LRUs which have the greatest expectation of 
being needed as a spare. Forecasting the times at 
which spares are needed requires consideration of 
many significant factors including, for example, 
failure rate, flight rate, spares availability, and 
desired level of support, among others. This paper 
summarizes the results of the research and 
development work that has been accomplished in 
producing an automated tool that assists in the 
assignment of effective repair start-times for LRUs 
at the NSLD. This system, called the Repair Start- 
time Assignment System (RSAS), uses 
probabilistic modeling technology to calculate a 
need date for a repair that considers the current 
repair pipeline status, as well as, serviceable 
spares and projections of future demands. The 
output from the system is a date for beginning the 
repair that has significantly greater confidence (in 
the sense that a desired probability of support is 
ensured) than times produced using other 
techniques. Since an important output of RSAS is 
the longest repair turn-around time that will ensure 
a desired probability of support, RSAS has the 
potential for being applied to operations at any 
repair depot where spares are on-hand and repair 
start-times are of interest. In addition, RSAS 
incorporates tenants of Just-In-Time (JIT) 
techniques in the connotation that the latest repair 
start-time (i.e., the latest time at which repair 
resources must be committed) may be calculated 
for every failed unit. This could aid in reducing the 
spares inventory for certain items, without 


Introduction 


The problem addressed by this research project 
was to produce a tool that could aid in reducing 
logistics operations costs while maintaining timely 
hardware availability to the Orbiter program, as 
well as, future space programs. Increasingly tight 
budget restrictions are continually putting greater 
pressure on the entire space program to reduce 
operations costs — or price itself out of business. 
Reductions in labor-intensive processes, coupled 
with novel approaches for providing the spare and 
repair aspects of logistics, are desperately needed. 
The broad objective of this project was to develop 
an advanced technology application that is capable 
of reducing labor intensity and production time for 
selected tasks currently performed in the logistics 
process. 


The research team investigated several possible 
areas within current Orbiter Logistics operations 
for application of advanced technology before 
finally deciding to focus on a new repair review 
board task. This area satisfied the criteria we felt 
necessary for a successful project of this nature. 
Those criteria were as follows: 

1. Experts performing the specific task must 
be available in-house, and willing to 
cooperate with the project. 

2. The potential for cost savings as compared 
to similar analyses performed manually 
must be clearly evident. 
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3. The required input data must be accessible 
to the research team. 

The intent of the repair review board was that a 
group of management level personnel from several 
Orbiter hardware support areas would meet at 
regular intervals throughout the year to assess the 
criticality of need of various items in for repair at 
the depot. Those items that have a sufficient level 
of support remaining for extended periods into the 
future represent situations where the repair could 
potentially be deferred indefinitely. This 
postponement of repair time has the potential for 
saving money by not expending valuable 
resources on non-critical items. Due to the 
complexity of Orbiter systems, the aging of the 
fleet, and relatively low flight rates corresponding 
to small sample sizes, a math model alone is 
recognized as insufficient for adequately 
determining need. Due to this shortcoming, the 
specific objective of this research grew into an 
investigation of the feasibility of combining expert 
system technology and probabilistic modeling to 
assist in assigning repair start times at the NASA 
Shuttle Logistic Depot (NSLD). The initial 
assessment of the benefits of the technology 
insertion indicated the potential for: 1) reduced 
labor intensity in the logistics product support 
area, 2) more uniform and consistent assignment 
of repair start times at the NSLD, 3) better 
planning and management control of capacity at 
the logistics depot, and 4) possibly assisting in 
the depot scheduling process. 

The concept for the selected system was to 
combine algorithmic models for computing 
Supportability Turn Around Time (STAT), 
discussed later in this paper, and heuristic 
knowledge of Logistics Engineering Experts into a 
decision support tool called the Repair Start-time 
Assignment System (RSAS). As it turns out, the 
process of selecting candidate repairs for deferral 
has an analogous, and complimentary process for 
determining priority of need. Since the logistics 
engineers at the depot are deeply familiar with the 
prioritization end of the problem (as opposed to 
seeking deferrals), and since selecting units with 
priority leaves a large quantity of items to be 
deferred by default, it was decided to make use of 
the available prioritization domain expertise. The 


tool's refined purpose is to aid logistics engineers 
at the NSLD in assessing Line Replaceable Unit 
(LRU) part items for priority of repair need. 
Those parts that rank low in the resulting priority 
can then be more intelligently, and safely 
examined for potential repair deferral. 

System Architecture 

The following requirements were established for 
the development of the RSAS system. As an 
initial approach, the prototype would be 
concerned with providing analysis for only those 
LRUs that are reparable at the NSLD. The 
prototype system was to be a stand-alone 
environment developed on a DOS/PC running 
under the MS/Windows 3.x operating system. 
The system input would be provided through a 
semi-automated data capture procedure, that could 
eventually be expanded to full on-line database 
access. System output would, at a minimum, 
consist of a probabilistic estimate of the likeliest 
number of days before the LRU repair operation 
should start, and a repair start-date that has been 
determined by backing out the number of days 
required (on average) to repair units of this type. 
This probabilistically determined need-date could 
then be adjusted heuristically by application of 
rules via an expert system knowledge base if 
appropriate. Figure 1 represents the architectural 
view of the RSAS prototype. The RSAS is 
modularly constructed from three distinct 
components: 1) Data Capture component, 2) 
Algorithmic component, and 3) Expert System 
component. The following sections provide a 
more detailed discussion of these components. 

Data Capture Component 

At the start of the project, the data items used by 
the logistics engineers in their decision making 
process was located in many different databases 
and report sources. Examples of some of these 
were the LE's Desk Report, Generalized System n 
(GSII) Repair File, Logistics Inventory 
Management System (LIMS), Material Inventory 
Control & Information System (MICIS), and many 
custom reports dynamically pulled down from 
various mainframe databases as necessary. A set 
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Fig 1. The Prototype Configuration of RSAS 


of templates were developed which identified the 
required data items used for an analysis and the 
data source. Using the templates, reports 
containing the data items for a selected group of 
parts in repair were generated and stored on a 
floppy diskette. The report files were then 
converted into individual dBase III files consisting 
of only the data items of interest from each source 
using a software application called Monarch Data 
Translator. 

Finally, the separate files were merged through 
appropriate use of the Structured Query Language 
(SQL) outer-join operation to form a 
comprehensive data input file for the RSAS. 
Space limitations prevent displaying a full row of 
typical input data elements; however, Table 1 is 
an example of a partial input file for the prototype 
RSAS. A complete table could have in excess of 
one hundred columns for each item in for repair. 
The information contained in the input file 
allowed the system to answer questions 
concerning, for example: Flight Power On Time 


(FPOT), Ground Power On Time (GPOT), 
whether the part's use is hourly or flight cycle 
based (HOUR), the expected Repair Turn Around 
Time (RTAT), both individual and group Vehicle 
Maintenance Demand Rate (IND_VMDR and 
GRPJVMDR), Quantity Per Vehicle for each 
Orbiter (QPV102, QPV103, QPV104, QPV105), 
and the serviceable spares available on the shelf 
(SPARES). There were a number of advantages to 
the data capture procedure just described. For 
example, it helped to automate the data capture 
process by providing a set of templates that 
identified the source of each required data item. 
The defined templates resulted in an efficient 
procedure for capturing decision data for many 
parts during a single batch run. System validation 
was also enhanced since, in most cases, we 
employed the same sources of data as the experts 
in performing their analysis. Finally, It was easy 
to modify the templates when new data items were 
incorporated into the analysis process and hence, 
maintenance of the data capture component was 
enhanced. By using a modular system design 
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Table 1. Example of Partial RSAS Data Input File 


FPOT 

HOUR 

RTAT 

GP0T 

CON 

1ND.VMDR 

GRP.VMOR 

GPV102 

QPV103 

GPV104 

QPV105 

SPARES 

260 

HRS 

96.66 

60 

0.9 

0.72 

0.72 

7 

7 

7 

7 

5 

260 

HRS 

96.66 

60 

0.9 

0.72 

0.72 

7 

7 

7 

7 

5 

260 

HRS 

96.66 

60 

0.9 

0.72 

0.72 

7 

7 

7 

7 

5 

260 

HRS 

34.86 

60 

0.9 

0.29 

0.29 

2 

2 

2 

2 

2 

8 

HRS 

113.51 

8 

0.5 

16.75 

16.75 

3 

3 

3 


5 


approach that separates the data capture 
component from the core processing element of 
the system, we increased the opportunities for 
using the RSAS system at various locations 
throughout the logistics program (e.g., HDA, 
management, the LE’s desktop machine, etc.). 
This also limited and localized the modifications 
required to the RSAS in the event that the 
mainframe LRU data repositories were 
substantially changed, which, as it turns out, is 
exactly what began to occur. After testing the 
system with the LEs for a short time, it was 
learned that many of the data systems we had been 
using were to be consolidated onto a local 
mainframe in Oracle 7 formats. With the modular 
approach, the data capture component is 
completely interchangeable. The prototype 
configuration shown in Figure 1 allowed the use, 
testing, and verification of RSAS based solely on 
data obtained from specific data query pulls. By 
replacing only the semi-automated front end with 
one capable of Oracle access, a fully automated 
system for assigning repair start-times to an entire 
inventory of repair items is possible. 

Alternatively, a desktop tool can be implemented 
where data input is provided interactively by a 
Logistics Engineer, or a member of management. 
This provides a what-if type of calculator never 


before available to the logistics engineering 
community. Such an implementation is shown in 
the screen capture image of Figure 2. 

The Algorithmic Component 

The principal feature of the Repair Start-Time 
Assignment System (RSAS) is the calculation of 
STAT values based on a desired level of 
probability-of-sufficiency (POS). POS is the 
probability of the event: "a spare is available to 
replace a failed unit." NASA defines the level of 
support that must be maintained for Orbiter 
systems. Thus, if POS = 0.90 = 90%, this means 
that when a unit fails, the inventory/repair system 
must be positioned such that 90% of the time a 
spare is immediately available for replacement. 
The term STAT is related to POS and indicates 
the maximum repair tum-around time permitted 
for a failed part that would still ensure a desired 
POS- value. In particular, for a failed Line- 
Replaceable Unit (LRU) not yet under repair at 
time t, STAT is the longest repair tum-around 
time from t that would ensure that the probability 
of no under-support during the interval t to 
r+STAT is POS (i.e., the probability is POS that a 
spare will be available for any unit that fails 
during t to r+STAT). 
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Repair Start-Time Assignment System (Algorithm Only) 
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Fig 2. Screen Capture Image of RSAS Implemented as Desktop Tool 


In order to calculate STAT values based on a 
given POS level for an LRU, modifications of 
equations conceptualized in notes from Dear were 
employed 1 . The Poisson process, and its 
associated probability law, is the fundamental 
building block used to obtain the equations from 
which STAT-values are found. Currently, the 
modifications and mathematical proofs of these 
equations are the subject of ongoing research 
whose findings and results will be reported in 
related papers 2 . Briefly, a STAT value is 
determined mathematically as the root of a 
particularly configured exponential equation that 
considers demand rate, available spares, and the 
quantity and respective completion date of like 
items in repair. It represents a reasonable starting 
point in the assignment of repair need-dates that is 
founded on accepted failure modeling practices , 
As of this writing, various automated root-finding 


techniques are under investigation. In any case, 
once a STAT-value has been found, subtracting 
the expected repair time (say E{R}) from the 
computed STAT-value will yield the latest time 
that repairs on this failed LRU may start. This 
idea is pictured in Figure 3 following. 

The Expert System Component 

The expert system component of the RSAS 
prototype was implemented using the Level5 
Object expert system shell 4 . The system 
knowledge base consisted of a set of rules elicited 
from the experts. The system level control of 
program flow for the prototype was also encoded 
into the rule base. Upon activation, the program 
evaluated and interpreted the input data file. 
Using data analysis logic encoded in the 
knowledge base, the program extracted and 
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ensures desired POS 


Fig 3. Graphical Representation of Latest Repair Start Time Based on STAT, 
POS, and Expected LRU Repair Time E{R} 


formulated the necessary input for the algorithmic 
component. It then activated the algorithmic 
processing which returned a value of STAT for a 
failed part that would ensure a given value of 
POS. Various additional pieces of data from the 
input file were then used by the expert system to 
adjust the algorithmically calculated STAT values 
by applying heuristic knowledge in a manner 
similar to the way the human experts would 
respond. The expert system component produced 
two forms of output. The first form was a 
graphical display utilizing MS-Windows interface 
controls to present processing results, to list the 
reasoning path taken in the derivation of those 
results, and to indicate any special exceptions 
encountered that would require additional human 
expertise. Second, the system could produce a 
hard copy report that presented the results of a 
complete analysis for a large quantity of repairs. 
Table 2 provides an example of a partial output 
file generated by the system. In the table, entries 
were made for every part number analyzed 
(PART.NUMBER, PART.NAME), the minimum 
(DMIN), maximum (DMAX), and best value 
(STAT) of days before this item is needed 
(calculated using the algorithm), the expert system 
adjusted repair start time (ARST), and notification 
of any rules fired due to unusual circumstances 


that still require human expert intervention 
(CONDITION, REASON). 

Although the Level5 Object expert system shell 
proved invaluable for prototype development, it 
was decided against using it in the final system 
due to the cost of licensing the distributable 
product. Instead, an embeddable form of the C 
Language Integrated Production System (CLIPS) 
expert system shell was developed 5 . Since CLIPS 
is a NASA developed package, it has no additional 
per seat licensing cost. Also, because of its highly 
procedural nature, the program control portion of 
the system was removed from the knowledge base 
and implemented in event driven code associated 
with the user interface. This greatly simplified the 
knowledge base, and made the final system 
tremendously more flexible and maintainable. 
Finally, since the expert system portion of RSAS 
is highly dependent on large amounts of data to 
make viable adjustments to the need-dates, and 
due to the major platform transition for data 
sources mentioned previously, it was decided to 
generate a version of the RSAS without the expert 
system module. The user interface for this 
version, shown previously in Figure 2, is currently 
in use by the LEs as of this writing. It provides 
for manual data entry only, and relies on the 


American Institute of Aeronautics and Astronautics 


51 


Table 2. Example of Partial RSAS Output Report 


PART_NUMBER 

PART_NAME 

DMIN 

STAT 

DMAX 

ARST 

CONDITION 

REASON 

MC409-0005-0045 

UNIT, HDSET 

31 

48 

69 

-48 



MC409-00 1 4-0006 

TACAN 

8 

5 

238 

-109 



MC409-001 5-0006 

RADAR ALTIME 

3,810 

4,098 

4,098 

4,064 



MC409-00 17-0006 

DECODER 

20 

0 

325 

0 

EXCEPTION 

Failure Analysis Required 


human expert to amend the need-date as 
necessary. A comment feature has been added so 
that the LE can annotate his reasoning for making 
adjustments to algorithmically calculated need- 
dates. This aids in refinement of the expert 
system knowledge base. 

Significance of Results 

■ The development of a working RSAS 
system through the combination of the three 
modules just discussed is the most 
significant result of this research. It 
demonstrates the feasibility of combining 
expert system technology and probabilistic 
models to produce repair start times having 
higher confidences than could be expected 
from an algorithm alone. This concept has 
the potential for being merged with a fully 
integrated repair scheduling system. 

■ The data capture component is significant in 
that it is a semi-automated process for 
obtaining large amounts of decision-specific 
data from multiple data sources through 
standard reports. It draws from the most 
recent sources available to provide high 
integrity decision data. Due to the 
modularity of the system, it can be modified 
or exchanged as required by changing data 
requirements or improvements in the data 
repositories. 

■ The expert system component is significant 
in that it attempts to make decisions by 
applying a set of heuristics captured from 
logistics engineering experts, similar to the 
way the experts would make decisions. 
Since the knowledge base contains a set of 


rules that represent the combined domain 
expertise of many logistics engineers, the 
results and decisions of the expert system 
component can be more uniform and 
consistent than those produced by the 
individual human experts. This feature 
leads to decisions that are inherently more 
programmatic. 

■ The algorithmic component is significant in 
that it calculates STAT values that take into 
consideration not only the number of spares 
on the shelf, but also the expected 
completion of units currently undergoing 
repair to provide a more accurate projection 
of the expected time of need for the unit 
under analysis. The use of this data is 
recognized as an important feature in the 
performance of local spares analysis. Also, 
it has led to an understanding of better ways 
of displaying data such as POS, repairs in 
process, and so on, that are more meaningful 
to the logistics engineers than a purely 
tabular format. 

Conclusions 

A prototype system combining expert system 
technology and probabilistic modeling was 
developed. This prototype demonstrated the 
feasibility of producing potential repair start-times 
for LRUs entering the repair process at the NSLD 
in an automated fashion. The system was 
designed with modularity and maintainability as 
central features. The need-dates produced by the 
RSAS were immediately recognized by the 
Logistics Engineers at the NSLD for their 
accuracy, and the overall system was quickly 
accepted for use due to its user friendly interface. 
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The system was easily extended into other types 
of hardware maintained at the depot, for example, 
Government Supplied Equipment (GSE). New 
areas for the system’s use continue to be pursued. 
It is expected that this application will eventually 
be integrated into a general repair scheduling 
system. 
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Accurate selection of the quantity of logistic 
support resources has a strong influence on 
mission success, system availability and the 
cost of ownership. At the same time the ac- 
curate prediction of these resources depends 
on the accurate prediction of the reliability 
measures of the items involved. This paper 
presents the method for the advanced and 
accurate calculation of the reliability mea- 
sures of complex space systems which are 
the basis for the determination of the de- 
mands for logistics resources needed during 
the operational life or mission of space sys- 
tems. The applicability of the method pre- 
sented is demonstrated through several il- 
lustrative examples. 

1. Introduction 


Practice shows that, in a majority of cases, 
the shortage of logistic support resources 
causes a much higher delay in performing 
a maintenance task than the delays caused 
by any other reason [2]. Consequently, the 
users select, control and manage resources, 
the quantity of which has a strong influence 
on system availability and the cost of owner- 
ship. An over-estimated quantity of results 
in a higher support cost with a great deal of 
capital tied up, whereas an under-estimated 
quantity results in a reduction of availabil- 
ity/profit. Therefore, the accurate predic- 
tion of the quantity and content of logistic 
support resources required is imperative for 
cost effective support of the operation and 
maintenance process. At the same time 


the accurate prediction of these resources 
depends on the accurate prediction of the 
reliability measures of the items involved. 

One of the most frequently used reliability 
measure, in engineering practice, is the haz- 
ard function, z(f), defined as: 


z(t) = 


m 

m 


(i) 


where: /(f) is a probability density func- 
tion of the random variable which represents 
time to failure, TTF, and R(t ) is a corre- 
sponding reliability function which quanti- 
tatively expresses the probability that the 
failure will not occur up to time f, P(TTF > 
t). Generally speaking, the hazard function, 
could be an increasing, decreasing or con- 
stant function of time, which depends on 
the real process of the change in the physical 
condition of the item analysed. In the case 
that the time to failure is modelled by the 
exponential distribution, the above function 
becomes: 


, v _ /W Aerp(-Af) 

Z R(t) exp(-Xt) 


( 2 ) 


The above expression has a constant value, 
and it is known as a failure rate. It is neces- 
sary to stress that Eq. 2 is applicable only 
in the cases where the time to failure can 
be modelled by the exponential probability 
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distribution, which is applicable to a time 
independent processes. 

Analyses of models which deal with the de- 
termination of the quantity of the logistic 
support resources needed [1],[4],[7],[8], shows 
that all of them are based on the failure 
rate. However, this assumption is not al- 
ways correct, because there are many items 
whose failures are influenced by the time de- 
pendent processes, like corrosion, thermal 
deformation, fatigue, bedding-in, and sim- 
ilar. In these cases the failure rate, which 
reflects a time independent process has to 
be replaced with a hazard function which 
represents a time dependent process. There- 
fore, the application of models based on the 
constant failure rate to the determination 
of number of spares needed and other re- 
sources for items whose hazard function is 
decreasing or increasing during operational 
life, could generate results far from optimal 

15]. 

Thus, the main aim of this paper is to demon- 
strate the approach to the reliability mod- 
elling of the complex systems which would 
provide correct results relative to the predic- 
tion of the demands for the logistic support 
resources. 


2. Present Practice 

In order to set up the scenario for this pa- 
per the very simple example related to the 
evaluation of the mean time to failure of the 
complex system, MTTFs, will be used. 

Thus, let as look at a system which consists 
of three items, say A, B, and C, connected 
in series from the point of view of reliabil- 
ity. The task is to calculate the MTTFs of 
the system, if the MTTF A = MTTF B = 
MTTFc — 1000 hours. 


This very simple problem could be easily 
solved by applying the following technique 
which is commonly used by mapy reliability 
practitioners. Thus, the failure rate of each 
module is \ A = \ B =z \ c = 1/1000 = 0.001, 
and as the items are connected in series the 
sum of their failure rates will give the failure 
rate of the system. Thus, the failure rate of 
the system is A 4 = 0.003 , which means that 
the mean time to failure of the system will 
be MTTF a = 333.3 hours. 

Many reliability engineers would finish the 
analysis at this point and use the obtained 
value for the MTTFs of the system in all 
further calculations related to the provision 
of the logistic support resources. 

Regarding this paper the above example is 
only the starting point. First of all, it is 
necessary to stress that the result obtained 
is valid only under the assumption of the 
constant failure rate. In cases where the 
items considered demonstrate increasing or 
decreasing failure rates during operational 
life this approach would provide an incor- 
rect solution. 

In order to illustrate the point made above, 
let us use the same example, but this time 
we shall fully defined the problem, which 
practically means that the process of the 
change in the condition of the items con- 
sidered will be defined. Instead of assuming 
the constant failure rate we shall specify the 
probability distributions of the time to fail- 
ures of the corresponding items, as shown in 
the table below: 

Now, we have fully specified the problem, 
but we do not have the fully defined algo- 
rithm for its solution, because the “classi- 
cal” reliability theory and available national 
and international standards do not address 
this problem in spite of the fact that it exists 
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Table 1. Reliability data for the items considered. 


Item 

Distrbtn. 
of TTF 

Parameters 

MTTF 

hazard 

function 

A 

Expntl. 

A = 0.001 

/ 

1000 

const. 

B 

Normal 

T5 

II 

O 

o 

o 

a = 375 

1000 

incrsn. 

C 

Weibull 

T) = 790 

© 

II 

1000 

decrsn. 


in every day engineering practice. 

Hence, this paper will present the algorithm 
for solving this and any other problem of 
forecasting and calculating the reliability mea- 
sures of complex engineering systems using 
the “bottom up” approach. 

3. Reliability measures of a Single 
Engineering Item 


In every day practice the occurrence of an 
uncertain event is described by the probabil- 
ity distribution of the chosen random vari- 
able through one of the well-known theo- 
retical probability distributions. The most 
frequently used distributions for continuing 
random variables, in the area of reliability, 
maintainability and support ability engineer- 
ing, are: exponential, normal, lognormal and 
Weibull [5]. Each of them represents a fam- 
ily of distributions where every member of 
the family is defined by some parameters, 
like: scale, shape and minimum value. Hence, 
if those parameters are specified the char- 
acteristics of probability distribution of the 
random variable like: expected value, E(X)] 
variance, V(X); cumulative distribution func- 
tion, F(x); probability density function, f(x ) 
and others, are fully known. 

It is necessary to say that the expected value, 
E(X), defined by mathematicians means ex- 
actly the same as the mean time to failure 
used by the reliability practitioners. Thus, 
X = TTF, and E(X) = F(TTF) = MTTF. 


Table 2 Illustrative example, input 


Distrbtn. 

Scale 

Shape 

MTTF 

TTF 10 

TTF 50 

TTFgo 

Expntl. 

1000 

0.00 

1000 

105 

693 

2303 

Normal 

1000 

150 

1000 

810 

1000 

1195 


1000 

300 

1000 

620 

1000 

1385 


1000 

450 

1000 

455 

1000 

1615 

Weibull 

1000 

1.00 

1000 

105 

695 

2303 


1115 

1.59 

1000 

270 

885 

1884 


1126 

2.67 

1000 

484 

981 

1539 


1100 

4.22 

1000 

645 

1008 

1340 


As the expected value is the subject of dis- 
cussion generated by this paper, let us re- 
member its general expression for the con- 
tinuous random variable, say X: 



( 3 ) 


where f(x) is the probability density func- 
tion of a random variable X. Applied to the 
time to failure, as a random variable, the 
above equation could be rewritten as [5]: 


OO 

F(TTF) = MTTF = J R(t)dt (4) 

o 

From the point of view of mathematics, MTTF 
defined as above is fully known characteris- 
tic, but what does it mean to logistics engi- 
neers? Not a lot, because it only defines a 
single point of the probability distribution. 

In order to illustrate this statement, several 
examples are given and in Table 2, each of 
which exhibits identical mean time to failure 
of 1000 hours. 

where; TTF P represents the length of oper- 
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ation up to which 10,50 and 90 percent of 
population will fail. The understanding of 
the behaviour of the random variable cannot 
be based on the information related to the 
expected value only. The last three columns 
in the above table clearly illustrates this state- 
ment. 

The impact of the type of the distribution 
and values of scale and shape parameters 
on the reliability measures is illustrated by 
Fig. 1. Clearly, the differences are signifi- 
cant. For example, the values of the relia- 
bility function at 500 hours for ail of them 
are scattered within a wide range of values 
(0.63 to 0.995). Certainly, there are an in- 
finite number of reliability functions mean 
value ( MTTF ) of which is equal to 1000 
hours, and each of them will have different 
values of reliability at different instances of 
operating time. 

The main objective of the example used was 
to show that it is absolutely crucial to un- 
derstand the process of change in the condi- 
tion of the item in order to get a full picture 
about its reliability measures. 


4. Reliability of Complex 
Engineering Systems 

In the cases where the random variable anal- 
ysed represents the complex event, its prob- 
ability distribution depends on the probabil- 
ity of occurrence of consisting events. From 
the point of view of mathematics, the com- 
plex event is any event which consists of 
two or more related events. The probabil- 
ity of occurrence of the complex event de- 
pends on the relationship between consist- 
ing events. For example, if the complex 
event is defined as the intersection of two 
or more events then the probability of its 



Figure 1. Reliability functions for several 
items with MTTF = 1000 hours 

occurrence is equal to the product of prob- 
abilities of occurrence of consisting events. 
Making use of equation 2, the expression for 
the mean time to failure of the complex sys- 
tem which is defined by the complex random 
variable, TTFs , will be: 


OO 

E(TTFs) = MTTF s = j Rs(t)dt (5) 

0 

where Rs(t) is the reliability function of the 
complex system. 

Clearly, the main problem facing the ana- 
lyst is the determination of the reliability 
function of the complex system, Rs(t). 

In the case that the consisting items (items, 
units, components) are independent and con- 
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nected in series, from the point of view of 
reliability, the reliability function of the sys- 
tem is defined as: 


nci 

R$(t) — n Ri(t) ( 6 ) 
1=1 

where: nci is the number of consisting items, 
Ri(t), reliability function of each consisting 
item representing the probability that the 
time to its failure is greater than t. Thus, 
the expression for the MTTFs of the com- 
plex system could be obtained by combining 
equations 5 and 6, thus: 





MTTFs = E(TTFs) = 


°? nci 

/n 

A 1=1 


Ri(t)dt 


(7) 


The above expression can be used for the 
calculation of the mean time to failure of 
the system, MTTFs , which consists of any 
number of items, which axe connected in se- 
ries from the point of view of reliability, and 
whose failure rate could exhibit any pattern 
of the failure rate, i.e. any mixture of in- 
creasing, constant and decreasing. 

In the cases where the analytical integration 
of the above expression is complicated, the 
required value could be obtained by using 
the graphical method. 


5.IllustrativeExample 


In order to illustrate the approach presented 
let as calculate the mean time to failure of 
the system whose consisting items are de- 
fined in Table 1. 

Making use of equation 7, the mean time to 
failure of the system of 363 hours, was ob- 
tained by applying graphical method. This 


Figure 2. Possible configurations of the system 


represents an increase of 10% in comparison 
with the corresponding value of 333.3 hours 
obtained by the “constant failure rate ap-^^ 
proach”. The differences between these twc^^P 
approaches to the determination of the re- 
liability measures are even more significant 
when they are used as a basis for the predic- 
tion of the demands for the logistic support 
resources. 

Based on the practical experience and the 
illustrative example used it is extremely dif- 
ficult to justify the use of the constant fail- 
ure rate approach to the calculation of the 
reliability measures for the complex systems 
which consist of the mechanical, hydraulic, 
pneumatic, and similar items. 

To illustrate further advantages of the method 
proposed, the situation where the increase 
of the reliability of the system is intended 
to be achieved by use of parallel configura- 
tion of two items of the same kind will be 
used, as shown in Figure 2. _ 
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Table 3. Reliability Analysis of Complex System 


Config. 

A 

B 

C 

MTTFs 

TTFl o 

TTFi 0 

TTFl o 

1 

1 

1 

1 

333 

35 

231 

767 

2 

1 

1 

1 

363 

25 

246 

849 

3 

2 

1 

1 

435 

35 

346 

978 

4 

1 

2 

1 

375 

25 

256 

949 

5 

1 

1 

2 

472 

75 

407 

989 

6 

2 

2 

2 

678 

165 

648 

1241 


In the case of the constant failure rate ap- 
proach it is irrelevant which item, A, B or 
C, should be connected in parallel, because 
the MTTFs will have identical. However, 
in all cases where the constant failure rate 
cannot be used as a model for the process 
of change in the condition of the consisting 
items, the above statement will be incorrect, 
as the Table 3 shows for the example used. 

The usefulness of the reliability analysis to 
the design regarding the selection of the op- 
timal configuration is obvious, especially in 
cases where due to weight, cost and space 
restrictions using a parallel configuration is 
very limited. The graphical representation 
of the pattern of the hazard function for 
each analysed configuration is given in Fig- 
ure 3. 

6 .Conclusion 

The main objective of the paper was to initi- 
ate a discussion on the accuracy of the deter- 
mination of the estimated values of the mea- 
sures of reliability and maintainability. The 
accurate way for calculating the expected 
value of the probability distribution of the 
random variable which represents the com- 
plex event has been demonstrated here. As 
a result of that, the accuracy of the mathe- 
matical models used by reliability, maintain- 
ability, and support ability engineers will in- 



Figure 3. Hazard function of the system caused 
for different configurations of its items. 

crease and in consequence the credibility of 
the profession should increase among other 
engineering disciplines. 

Based on several simple examples and brief 
theoretical analysis it is possible to learn the 
following lessons, from this paper: 

a) The calculation of the expected value 
of the complex random variable cannot 
be based on the information related to 
the expected values of consisting events 
only. The type and parameters of the 
probability distributions of the consist- 
ing events are of crucial importance for 
the accurate results, as demonstrated; 

b) The accuracy of the calculation of the 
expected values for the measures like: 
Mean Time To Failure, ( MTTF ), Mean 
Time Between Failure, ( MTBF ), and 
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similar, could have crucial effects to the 
final results of the reliability analyses, 
especially in the cases of engineering 
systems which consist of several thou- 
sand components. 

It is important to underline that the 
same conclusion is applicable to the calcu- 
lation of the expected values of the random 
variables which describe other types of con- 
figurations of the system (parallel, mixed, 
m out on n) as well as measures of main- 
tainability and supportability [2], 
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Abstract 

Among the maintenance resources, the spare 
parts are the most difficult to predict. Items 
in the space systems are very different from 
the point of view of reliability, cost, weight, 
volume, etc. The different combinations of 
spares make different contribution to the: 
mission success, spare investment, volume 
occupied and weight. Hence, the selection of 
spares for a mission planned must take into 
account all of these features. This paper 
presents the generic mission success driven 
sparing model developed, for the complex 
space systems. The mathematical analysis 
used in the model enables the user to se- 
lect the most suitable selection of the spare 
package for the mission planned. The illus- 
trative examples presented clearly demon- 
strate the applicability and usefulness of the 
model introduced. 

1. Introduction 

The main objective of any space system is to 
fulfil required mission. In majority of cases 
during the operational mission of repairable 
space systems the lead times for obtaining 
the replenishment are very long and often 
impossible. Thus, to ensure the accomplish- 
ment of the space mission, all the logistic 
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support resources necessary for the comple- 
tion of maintenance tasks required must be 
carried with the space vehicles along their 
missions. Due to the limitations on the load 
and space, it is impossible to carry as much 
resources as one would like to ‘double’ en- 
sure the provision of these resources. Clearly, 
the accurate estimation of resources needed 
is of the great importance for the successful 
completion of space missions. 

The sparing problem related to the spares 
stocked at the base has been well addressed 
by the models in literature and the com- 
mercial software. However,, the sparing for 
the successful completion of an space mis- 
sion has not yet been analysed as a specific 
problem. Rirthermore, the methods for the 
determination of the quantity of spares used 
by the existing sparing models are based 
on constant failure rate. In reality, the be- 
haviour of items can be modelled by any 
type of well-known probability distributions, 
which means that the failure rate could be 
increasing or decreasing function of the lengtl 
of operational time. Consequently, the ap- 
plication of the constant failure rate behaviou 
to all items could lead to significant error. 

The aim of the paper is to present the model 
for the determination of the number of spares 
required for the successful completion of the 
mission planned, based on the criteria like, 
the required availability, costs, weight and 
similar, which is also able to cope with the 
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cases where the behaviour of the items dur- 
ing the operation could not be modelled by 
the constant failure rate approach. 

From logistic point of view, all consisting 
items of a repairable system could be dis- 
carded or repaired, after their failures. This 
paper, for the sake of simplicity, focuses on 
the sparing for discard items. The simi- 
lar analysis method can be applied to re- 
pairable items. 

In order to address the sparing problem fully, 
it is assumed in this paper that all the other 
resources needed are available as called. Con- 
sequently, the spares are the only factor that 
has primary effect on the mission comple- 
tion. 

2. Measures of Space Mission Success 

During a mission of the system, the fail- 
ure/restoration cycle is repeated until the 
accomplishment of the mission, given that 
the resources needed for the maintenance 
are sufficient enough. Otherwise, the ter- 
mination of the mission could be required 
before its completion. 

Due to the randomness of the occurrence of 
failures, the successful completion of a space 
mission is a probabilistic event. Hence, the 
mission success, MS can only be quanti- 
fied through the probability. In the case 
that n spares are stocked on the board, the 
space mission will be accomplished if less 
than or equal to n failures occurred. Hence, 
the probability of mission success is just the 
probability that the cumulative number of 
failures during the mission is less than n + 1. 
Thus, the criterion for the determination 
of the quantity of spares for this type of 
missions could be defined as the probabil- 
ity that the total number of failures is less 
than n + 1. 


3. Sp aring Model for a Single Item 

Considering a single item the following as- 
sumptions are made: 

1) the time to failure of the item is mod- 
elled by pdf f(t), whose CDF is F(t), 
which can be represented by any type 
of probability distribution; 

2) the length of the mission is T m ; 

3) at the beginning of the mission the total 
amount of n spares are supplied; 

4) no replenishment spares will be obtained 
during the mission; 

5) the time to replace the failed item is 
much less than the length of the mission so 
that the replacement can be viewed as in- 
stant. 

The main question is how many spares are 
needed for the successful completion of the^ 
mission planned?. 

The probability of the mission success, in 
this case, is equal to the probability that 
the Number of Failures during the mission, 
NF(T m ), is less than or equal to the number 
of spares, n. This is, of course, the function 
of the length of mission, T m , and the num- 
ber of spares, n, and denoted as MS(T m , n), 
thus : 

MS(T m ,n) = P(NF(T m )<n). (1) 

According to renewal theory [1], the proba- 
bility that the number of failures in time T m 
is less than or equal to n can be expressed 
as following: 

P(NF(T m ) < n) = 1 - F n+1 (T m ), (2) 
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where F n+1 (t ) is the (n + 1) fold convolu- 
tion, defined as: 


F n+i (t) = J F n (t — u)dF(u) (3) 

o 

and F J (t) is Fi(t) defined in (2). Thus, 

MS(T m ,n) = 1 — F n+1 (T m ). (4) 

For the required Mission Success, MS r , the 
number of spares required, n r , to be carried 
along with the mission can be determined 
as follows: 


n r = m.m{n\MS(T m ,n) > MS 1 "}. (5) 

Tl 

For the hypothetical three items the mission 
success have been calculated and the results 
obtained is presented in the following table. 

where: r>, represents the number of spares 
at the beginning of the mission, MS(n ) is 
the Probability of mission success, given n 
spares at t = 0. The above data clearly 
show that the spare requirements satisfying 
the same MS are of significant difference 
resulting from the different failure time dis- 
tributions, and that, in particular, the con- 
stant failure rate assumption, i.e. exponen- 
tial distribution, adopted by conventionally 
used method for sparing causes remarkable 
error due to ignoring the true distribution of 
the item’s failure time distribution, govern 
by the mechanism of failure. 

4. Optimal Sparing Model for a System 


Item 

1 

2 

3 

Distribution 

Exponential 

Normal 

Wei bull 

A 

500 

500 

54 

B 

- 

150 

0.3 

MTTF 

500 

500 

500 

MTTR 

50 

50 

50 

T 

± m 

1000 

1000 

1000 

n 

MS( n) 

MS(n) 

MS(n) 

0 

0.0005 

0.00000 

0.0000 

1 

0.3135 

0.4971 

0.4122 

2 

0.6264 

0.9702 

0.6641 

3 

0.8349 

0.9994 

0.8132 

4 

0.9392 

0.9999 

0.8988 

5 

0.9809 

1.0000 

0.9466 

6 

0.9948 

1.0000 

0.9725 

7 

0.9987 

1.0000 

0.9862 

8 

0.9997 

1.0000 

0.9932 

9 

0.9999 

1.0000 

0.9967 

10 

1.0000 

1.0000 

0.9985 


The objective of sparing for a space mis- 
sion is to optimally determine the quanti- 
ties of spares for each reliability critical item 
in the system to ensure the accomplishment 
of the mission, whilst the specified optimi- 
sation target, such as cost and weight, im- 
posed upon spares can be achieved. This 
problem is usually known as optimal spare 
allocation. 

The optimal spare allocation problem is solved 
in existing commercial model by using con- 
stant failure rate method [3] [4], However, 
this method is not really optimal. In [5] 
a dynamic programming model to minimise 
the total spare cost subject to the required 
availability has been presented in [5]. For 
the space mission, in some cases, the total 
weight or the total volume is the major con- 
cern in sparing analysis. In this section, the 
dynamic programming technique has been 
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used in order to solve the optimal spare al- 
location problem, which is: to minimise the 
total weight of spares subject to the required 
probability of space mission success. 

4.1 Dynamic Programming Model 

Suppose that the system under considera- 
tion consists of n items, all items are mu- 
tually independent and connected in series 
from the reliability point of view. Let Wi de- 
note the total weight of spares for item i, Pi 
the achieved probability of mission success 
of item i,andP 3 the required probability of 
mission success of the system. The opti- 
misation problem indentified above can be 
formulated as follows : 

n 

min^W,- (6) 

1=1 

subject to 

n 

n p i > p ‘ co 

t=i 

Equations 6 and 7 represent the target func- 
tion, and constraint of the problem, respec- 
tively. 

This problem is converted to a dynamic pro- 
gramming model, where the following no- 
tations are adopted, for each item i, (i = 
1, . . . , n), and the system: 

di : decision variable 
Di : decision space 
s, : state variable 
S, : state space 

P x (k) : mission success probability with re- 
spect to k spares available 
Wi : total spare weight 


W a i : unit spare weight 

Ri(.) : return function 

Fi(.) : optimal return function 

The parameters in the D.P. model are spec- 
ified as below: 

1) Stage i : each item of the system is defined 
as a stage. There are n stages altogether in 
the model; 

2) Decision variable d, : the number of spares 
allocated to the zth item at stage i,i = 1, . . . , 

3) State Variable, s t : the probability of mis- 
sion success of the part of the system from 
item n up to item i + 1; Note that s n , the 
state variable at stage n, is equal to one. 
The transfer function can be expressed as 
below: 

s t — i — S{ x P(d, ), i = 1 , . . . , n, (8) 

where P(.) is equation (7). Thus, state vari- 
able s 0 is just the mission success probabil- 
ity of entire system. 

4) Return function, R,(d,): Each value of deci- 
sion variable indicates possible spare num- 
ber allocated to an item. The return from 
decision is defined as the total spare weight 
of the item: 

Ri(d{) — W a i x dj, i = 1, . . . , n. (9) 

5) Optimal Return Function of Stage i, Fi(si) : 
the optimal value of cumulative spare weight 
from stage 1 up to stage i, which can be de- 
fined as follows : 


F,(s t ) = min [Ri(si) + F { - l(s, - 1)]. (10) 

di 
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Item 

1 

2 

3 

Unit Weight 

1.5 

1 

2 


n 

Item-1 

MS W 

Item-2 

MS W 

Item-3 

MS W 

3 

- 

- 

0.9895 

3 

- 

- 

4 

- 

- 

0.9998 

4 

- 

- 

5 

0.9809 

7.5 

1.0000 

5 

- 

- 

6 

0.9948 

9 

- 

- 

0.9803 

12 

7 

0.9987 

10.5 

- 

- 

0.9906 

14 

8 

0.9997 

12 

- 

- 

0.9956 

16 

9 

0.9999 

13.5 

- 

- 

0.9980 

18 

10 

1.0000 

15 

- 

- 

0.9991 

20 

11 

- 

- 

- 

- 

0.9996 

22 

12 

- 

- 

- 

- 

0.9998 

24 


Due to the limitation of the size of the pa- 
per, the algorithm of implementing the model 
is left out. Readers who are interested in it 
can refer to [5]. 

The following example demonstrates the ap- 
plication of the above D.P: model for opti- 
mal allocation of the mission spare. 

Considering the hypothetical items defined 
in Table 1, the unit weight of each is given 
below: 

The objective of the example is to minimize 
the total weight of spares, while the system’s 
probability of the mission success probabil- 
ity of 0.98 is to be met. The feasible value 
of number of spares and associated MS(n ) 
and weight for each item are listed as below: 

The results of spare requirement allocated 
to each item are in the following: 

5 Conclusion 

This paper addresses the problem of spar- 


Item 

1 

2 

3 

System 

n 

6 

4 

7 

- 

MS 

0.9948 

0.9998 

0.9906 

0.9853 

w 

9 

4 

14 

27 


ing analysis driven by the mission success. 
Firstly, the measure of mission success, namely 
the probability of mission success was de- 
fined, which forms the criteria for sparing 
optimisation. Secondly, the mission spar- 
ing model for a single item was developed 
in terms of failure time distribution instead 
of constant failure, which is conventionally 
applied, by using renewal theory. Finally, 
the dynamic programming model for the op- 
timal spare allocation to the entire system 
was developed, where the weight of spares 
was used as the decision criterion. 

The model developed and the examples cited 
shown that the type of the failure time dis- 
tribution and its parameters have strong in- 
fluence on the solution of sparing analysis, 
which constant failure rate method ignores. 
Consequently, the calculation of spare re- 
quirement by the model developed is signif- 
icantly improved. 
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ABSTRACT 

Early in the development of the Space Station it 
was determined that there is a need to have a 
vehicle which could be used in the event that the 
Station crew needed to quickly depart and return 
to Earth when the Space Shuttle is not available. 
Unplanned return missions might occur because 
of a medical emergency, a major Station failure, 
or if there is a long-term interruption in the 
delivery of logistics to the Station. The rescue 
vehicle was envisioned as a simple capsule-type 
spacecraft which could be maintained in a 
dormant state at the Station for several years 
and be quickly activated by the crew when 
needed. 

During the assembly phase for the International 
Space Station, unplanned return missions will be 
performed by the Russian Soyuz vehicle, which 
can return up to three people. When the Station 
assembly is complete there will be a need for 
rescue capability for up to six people. This need 
might be met by an additional Soyuz vehicle or 
by a new vehicle which might come from a 
variety of sources. This paper describes one 
candidate concept for a Space Station rescue 
vehicle. This concept was developed by 
engineers at the Johnson Space Center. 

The proposed rescue vehicle design has the 
blunt-cone shape of the Apollo command 
module but with a larger diameter. The rescue 
vehicle would be delivered to the Station in the 
payload bay of the Space Shuttle. The 
spacecraft design can accommodate six to eight 
people for a one-day return mission. All of the 
systems for the mission including deorbit 
propulsion are contained within the conical 
spacecraft and so there is no separate service 
module. The use of the proven Apollo re-entry 
shape would greatly reduce the time and cost for 
development and testing. Other aspects of the 
design are also intended to minimize 
development cost and simplify operations. This 
paper will summarize the evolution of rescue 
vehicle concepts, the functional requirements for 
a rescue vehicle, and describe the proposed 
design. 


cDsfaoP 

PURPOSE OF THE RESCUE VEHICLE // ^ 

The International Space Station has a multi-year 
mission during which many astronaut and 
research crew members will occupy the Station. 

The crew members will reach the Station in the 
Space Shuttle, Soyuz spacecraft, or other crew 
transport vehicles. The Station and its crews will 
be dependent on the regular delivery of supplies 
by the Shuttle and other transport vehicles. The 
transport vehicles will arrive and depart on pre- 
determined schedules. It will be difficult in the 
case of the Soyuz and even more difficult in the 
case of the Shuttle, to launch a mission with 
crew or supplies ahead of schedule. 

It was recognized early in the Space Station 
development program that a situation might 
develop in which a crew member might need to 
be transported to the ground ahead of schedule 
because of a serious illness or injury. Also, a 
serious system failure aboard the Station might 
make an immediate evacuation and return to 
Earth necessary. Finally, if a launch vehicle 
failure occurred, the interruption of supply 
deliveries might require the eventual evacuation 
of the Station crew in a vehicle other than the 
one which failed. These three scenarios 
correspond to the three missions for a Space 
Station rescue vehicle: 

• medical evacuation 

• immediate return in case of a Space Station 
failure 

• return in case crew rotation and re-supply are 
interrupted by a launch system failure 

A variety of means for providing emergency 
crew return were considered by the Space 
Station Program. The option of keeping a Space 
Shuttle Orbiter docked at the Station for the 
entire crew rotation period has many advantages 
but requires that the Orbiter be modified for long 
duration flight. The option of maintaining a 
Space Shuttle on standby for immediate launch 
to the Station in an emergency was deemed to 
be impractical. Co-orbiting vehicles and safe- 
haven concepts were considered too 
complicated and costly. It was concluded that a 
separate vehicle, docked to the Station at all 
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times, was the most effective means of providing 
emergency crew return capability. 

It should be noted that in the operation of the 
Salyut and Skylab space stations, the transport 
vehicle for the crew always remained docked to 
the Station so it was available for use by the 
crew at any time. The current Mir station is also 
operated in this manner. In the case of the 
International Space Station, the Space Shuttle 
will remain docked for short times but leave 
crews onboard when it departs. The Soyuz 
spacecraft, with three seats, will be used by the 
Russians for crew transport and will remain 
docked as long as the crew is present. The 
Soyuz therefore provides immediate return 
capability which is sufficient during the assembly 
phase when the number of crew will not exceed 
three unless the Shuttle is present. 

Following the assembly phase, the normal 
Station crew number is expected to be six. 
Assuming that three people can be returned in 
the Soyuz that is always present for Russian 
crew rotation, there is still a need for rescue 
capability for three more people. The additional 
rescue capability could be provided by having 
two Soyuz present or by adding another rescue 
vehicle. 

The use of two Soyuz vehicles to provide 
complete rescue capability remains a viable 
option for the Space Station. Other approaches 
continue to be considered because of some 
limitations in Soyuz capability. The Soyuz is 
designed for a service life of six months and 
would require replacement at a rate that 
exceeds that required for Russian crew rotation. 
This implies that an extra Soyuz spacecraft 
would have to be manufactured and flown to the 
Station every six months for the purpose of 
providing rescue capability. 

Another limitation is that the American astronaut 
population currently includes many members 
who exceed the Soyuz height limit of 1 82 
centimeters. For descent in the Soyuz, all 
occupants wear pressure suits which could 
restrict the ability to return a seriously ill or 
injured crew member. The very limited internal 
volume and compact seating arrangement in the 
Soyuz also limit its effectiveness for medical 
evacuations. 

Some modifications to make the Soyuz more 
compliant with rescue vehicle requirements have 
been under consideration and these changes, if 
implemented, would increase the possibility of 


using Soyuz spacecraft as rescue vehicles 
throughout the lifetime of the Space Station. 
However, because of the uncertainties about the 
potential modifications and long-term availability 
of the Soyuz, other options have continued to be 
considered. 

CONCEPT EVOLUTION 

During the period of Space Station development, 
a number of rescue vehicle concepts have been 
developed. Several design studies that 
influenced the design in this paper should be 
noted. One of the first Station rescue vehicle 
concepts which was developed in 1 986 by an 
engineering team at the Johnson Space Center 
was a six-person Apollo-shaped spacecraft with 
a 4.4-meter diameter and a separate service 
module (Reference 1). Soon after that another 
team developed a concept which came to be 
known as the SCRAM. The SCRAM design has 
a cylindrical pressure vessel for six people sitting 
on a conical heatshield (Reference 2). Later the 
SCRAM concept was modified to accommodate 
eight people (Reference 3). 

In 1 992, in response to a request from NASA 
management, a concept was developed for a 
two-way crew transport with the groundrule that 
the development would be done by civil service 
employees using government facilities as much 
as possible. This "in-house" approach was 
emphasized in an effort to minimize the eventual 
cost of the spacecraft. The concept developed 
in this study was a four-person Apollo-shaped 
vehicle with a separate service module. As a 
crew transport, the spacecraft would be 
launched on an expendable launch vehicle and it 
carried an Apollo-type launch escape rocket 
(Reference 4). In 1994, the two-way transport 
design was adapted to the requirements of a 
one-way Station rescue vehicle which resulted in 
the design described in Reference 5 and in this 
paper. As part of the design studies for the "in- 
house" crew transport and rescue vehicles, the 
team defined a detailed development plan 
including all engineering activities from concept 
definition to delivery of the flight units. This 
development plan was the basis for a 
comprehensive schedule and cost estimate 
including all labor and materials. 

STUDY GROUNDRULES 

The specific design concept described here was 
intended to meet all the basic requirements for a 
Space Station rescue vehicle and was also 
developed with some unique groundrules: 
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• Development work would be performed by civil 
service personnel using government facilities 
as much as possible 

• The spacecraft would be delivered to orbit in 
the payload bay of the Space Shuttle 

• Ocean recovery would be acceptable 

• Reusability would not be required 

• The conceptual design would include the 
definition of the complete development and 
fabrication process and a detailed costestimate 

• Two operational spacecraft would be built 

• There would be an orbital flight test 

FUNCTIONAL REQUIREMENTS 

Missions : The purpose of the rescue vehicle is 
to return Space Station crew members in case of 
a medical emergency, a Space Station failure 
which requires immediate evacuation, or the lack 
of availability of the Space Shuttle fora normal 
return. The spacecraft must separate from the 
Station, loiter in-orbit for up to 24 hours, perform 
a deorbit maneuver, descend through the 
atmosphere, and land safely. 

Capacity : Six to eight people with minimal 
provisions. 

Duration : 36 hours in an active mode (24 hours 
for loiter, deorbit and landing plus 12 hour 
margin) 5 years docked to the Station in a 
quiescent mode, using power from the Station 
(continuous Station power requirement should 
not exceed 300 watts.) 

Operations : Automatic operation for all functions 
with manual intervention possible for some 
critical functions 

Delivery to Orbit : The spacecraft will be 
delivered to the Space Station in the payload 
bay of the Space Shuttle Orbiter. A support 
structure for this purpose must be defined. 

Berthing : The spacecraft must accommodate 
berthing by a remote manipulator to a berthing 
port on the Space Station and therefore must 
have a grapple fixture and a berthing 
mechanism. Active rendezvous and docking is 
not required. 

Cabin Atmosphere : Standard oxygen and 
nitrogen mixture at 1 atmosphere. Pressure 
suits will not be worn by personnel for descent. 
Extra-vehicular activities are not required. 

Communications : Two-way communication for 
voice, telemetry, and commands with the Space 


Station and the ground control center is 
required. 

Recovery : The primary mode is water recovery 
at a coastal site near the Kennedy Space 
Center. There should be backup water sites. 
Emergency land impact must be survivable. 

Safety : AH systems are fail-safe for crew return 
or designed with adequate safety margins where 
redundancy is not practical. 

Mission Timeline : The mission is planned for 
normal recovery at a coastal water site near the 
Kennedy Space Center (KSC). A typical mission 
timeline is provided below. 

Hrs:min 

00:00 Separation from Space Station 
01 :45 Deorbit for first landing opportunity to 
KSC site 

02:30 Landing and recovery 
02:45 Deorbit for second landing opportunity to 
KSC site (contingency) 

24:45 Deorbit for third landing opportunity to 
KSC site (contingency) 

Velocity Increment : 

Separation 1 .0 meter/second 

Deorbit 119.0 meters/second 

Total 120.0 meters/second 

CONCEPT CONFIGURATION 

The rescue vehicle concept is shown in Figure 
1 and described below. A dimensioned 
drawing of the crew module segment is shown 
in Figure 2. 

Structure and Thermal Protection : The 
exterior shell of the crew module is the same 
shape as the Apollo command module. 

However, its base diameter is increased to 
4.42 meters (14.5 ft) to provide greater 
volume. This diameter will still allow the crew 
module to fit within the payload bay of the 
Space Shuttle. 

The primary structure is an aluminum-2219, 
skin-stringer construction. The pressure vessel 
is a separate structural assembly of welded 
aluminum-2219 located inside the exterior shell 
of the crew module. For thermal protection, the 
base of the crew module is covered with ceramic 
tiles which are similar to the tiles on the Space 
Shuttle Orbiter. The conical section is covered 
with flexible blanket insulation which is similar to 
the material on the Shuttle Orbiter upper 
surfaces. 



The crew module has windows and a side hatch 
which are similar to the Apollo command 
module. The transfer tunnel at the apex is a 
scaled-up version of the Apollo design. In order 
to be compatible with the docking port on the 
Space Station, a separate docking adapter is 
attached to the transfer tunnel. In this design 
the docking mechanism is the Androgynous 
Peripheral Attachment System (APAS). In an 
emergency mission, the spacecraft would 
separate from the docking adapter when 
departing and the adapter would remain 
attached to the Station. 

The spacecraft structure must include a grapple 
fixture so that a remote manipulator can remove 
the spacecraft from the Shuttle payload bay and 
attach it to the docking port on the Space 
Station. 

Propulsion : The crew module propulsion system 
provides attitude control and is used for the 
deorbit maneuver. It is a unique feature of this 
design, compared to other capsule concepts, to 
include the deorbit propulsion capability in the 
crew module rather than adding a separate 
service module. The relatively large volume of 
the crew module makes this possible. The 
benefits of this feature are a major reduction in 
vehicle interfaces, the opportunity to recover and 
reuse the propulsion system components, and 
the elimination of sen/ice module impact 
concerns which greatly expands landing zone 
options. 

The propulsion system is based on the Apollo 
command module design with two additional 
thrusters. There are fourteen pressure-fed bi- 
propellant thrusters with scarfed nozzles. Each 
thruster develops a vacuum thrust of 445 
Newtons (100 pounds-force). The propellants 
are monomethyl-hydrazine and nitrogen 
tetroxide stored in eight tanks. 

Power : Since the vehicle is delivered as a 
payload by the Space Shuttle and may remain 
attached to the Station in a dormant state for 
several years, reserve batteries are used. 

These batteries are not activated until needed at 
the time of an emergency mission. External 
power from the Space Station would be used 
for thermal control, status monitoring, and 
periodic checkout but that power requirement is 
not expected to exceed 300 watts. The 
maximum power level for the rescue vehicle, 
when activated, is estimated to be a little more 
than 3 kilowatts. The design has 16 battery 
modules packaged in two units. The power 


distribution system includes control units and 
conversion units to provide alternating current as 
well as direct current at 28 volts. There are two 
main direct current buses and two alternating 
current buses. 

Avionics : The rescue vehicle must provide its 
own capability for navigation and 
communications. The design includes an 
integrated inertial navigation system and star 
trackers. There are also global 
positioning system (GPS) receivers and 
antennas. The avionics sensors are linked to 
general purpose 

computers which communicate to other 
components, including the attitude control jet 
drivers, through multiplexer-demultiplexer units. 

Displays and Controls : There is a caution and 
warning system to monitor the major crew 
module systems and alert the crew through 
audio tones and warning lights if there are 
problems. All spacecraft functions are 
automated but there are provisions for crew 
intervention in critical functions. There is a 
limited set of approximately 20 circuit breakers 
and 20 switches, but most of the crew interaction 
with systems is through multi-function electronic 
display screens and programmable pushbutton 
panels. There is also a rotational hand controller 
and a translational hand controller for manual 
maneuvers. 

Communications : The crew module has UHF 
and S-band radio systems for communication 
with the ground. There is a search and rescue 
communication system (SARSAT) for use after 
landing and a set of personal handheld radios 
for emergency use after landing. An audio 
system in the crew module provides for voice 
communication through individual headsets and 
speakers. 

Life Support and Active Thermal Control : 

Oxygen for breathing is provided from storage 
tanks and nitrogen is available for re- 
pressurization if needed. Carbon dioxide is 
removed from the cabin air with lithium 
hydroxide (LiOH) canisters. A fan circulates 
cabin air and provides for air flow through the 
lithium hydroxide canisters. 

There is a cabin air heat exchanger which also 
controls cabin humidity. All system components 
which generate heat are mounted on cold plates 
which are cooled by circulating water. Waste 
heat is rejected by a water flash evaporator 
system. 


70 



Landing : The crew module is decelerated during 
descent by a drogue parachute and then a 
cluster of three large ring-sail parachutes. The 
diameter of each parachute is 26 meters. The 
expected velocity at impact is 7.6 
meters/second. After landing in the water, 
flotation bags, similar to those used on the 
Apollo command module, will be inflated to 
ensure that the crew module is turned upright 
and remains upright during the recovery phase. 

A diagram of the main parachute cluster is 
shown in Figure 3. 


docking mechanism on its own support structure 
in the payload bay as shown in Figure 4. 

The forward support structure, along with the 
simulated docking mechanism, would remain in 
the payload bay following deployment. It could 
be used on future refurbishment missions to 
bring back the rescue vehicle. Because of its 
relatively compact volume, there will be enough 
room in the payload bay to return other payloads 
from the station after the rescue vehicle is 
removed. 


Land recovery using a deceleration system 
might be achieved with a moderate increase in 
development cost. Compared to water recovery, 
land recovery is in some ways safer, recovery 
operations are less costly, and reuse of 
hardware is more practical. 


Pyrotechnic Devices : There are pyrotechnic 
devices associated with the following systems 
and interfaces: 

- propellant isolation valves 

- docking mechanism emergency separation 

- parachute system cover and parachute 
deployment 

- flotation system. 


Crew Accommodations : The crew module can 
have up to eight couches to accommodate the 
crew members during descent. The couches 
are supported by attenuating struts which reduce 
the impact acceleration at landing. The crew 
members will not wear pressure suits. 

Additional provisions include drinking water, 
food, equipment for food preparation, personal 
hygiene, waste management, and emergency 
survival. 


Accommoda tion in Space Shuttle Pavload Bav : 
The rescue vehicle will be delivered to space 
station in the Space Shuttle and may need to 
return in the Shuttle in the case of a launch abort 
or for refurbishment after its operational life is 
exceeded. In either case, it requires support 
structure to secure it in the payload bay during 
launch and landing. 


The attach structure concept involves two 
longeron trunnions and one keel trunnion 


attached directly to the spacecraft just forward of 
the heat shield to support the mass of the crew 
module. The trunnions will be attached to 
standard payload bay latches and bridges. The 
docking adapter at the forward end of the 
spacecraft would be "docked" to a simulated 


It was assumed that the Space Shuttle remote 
manipulator will be used to unlatch and remove 
the vehicle from the payload bay. The grapple 
fixture will be located on the docking adapter 
assembly. 

Mass Properties : A three-dimensional computer 
solid model was used to investigate various crew 
module configurations and to estimate center of 
gravity and moments of inertia. Eight people 
can be located inside the crew module, although 
6 or 7 people could be accommodated more 
comfortably. The vehicle center of gravity and 
moments of inertia were calculated from the 
masses of individual components modeled in the 
computer solid model. The mass estimate for 
each major subsystem is shown in Table 1. 


DEFINITION OF DEVELOPMENT PLAN 

The cost estimates for labor and materials and 
the detailed development schedule produced in 
this study are considered sensitive information 
and are not included in this paper. However, the 
process followed in preparing the estimates is 
summarized below. 

The first step in preparing the cost estimate is to 
define all of the development activities. In the 
original two-way personnel transport vehicle 
study (Reference 4), technical specialists in 
each area defined all of the activities which must 
be done, how long each activity would take, how 
many people would be required to perform the 
activity, and what materials, equipment, special 
skills, and facilities would be required. For the 
rescue vehicle study, these technical specialists 
were contacted again to determine changes to 
their former estimates to reflect the difference in 
the mission and vehicle. The work breakdown 
structure includes all of the spacecraft technical 
disciplines as well as systems engineering and 
integration functions for all phases of the 
program. 
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CONCLUSION 


All phases of the development program were 
considered from requirements definition and 
conceptual design through fabrication and 
testing of the qualification and flight units. 
Approximately 900 activities were defined. 
Requirements for material and personnel travel 
were also identified. All of the development 
activities were integrated into a master schedule. 
Resource estimates were based on vendor 
information, previous experience, and other 
programs. 

All activities were arranged in a logical sequence 
and some optimization was done to control the 
duration of the schedule. The critical path 
includes those activities which drive the overall 
length of the schedule. Structural design, 
fabrication, and assembly are the most 
significant activities on the critical path, however 
activities related to propulsion, avionics, 
electrical power, and thermal protection systems 
also appear on the critical path. The experience 
gained at the Johnson Space Center in the in- 
house fabrication of a structural article for the 
Aero-assist Right Experiment project provided 
the analogy for schedule estimates for structure 
and thermal protection system fabrication and 
assembly. 

The following tests were included in the 
schedule and cost estimates: 

• Subsystem and qualification tests for all 
components 

• Static structural tests 

• Vibro-acoustic tests 

• Thermal-vacuum tests 

• Electro-magnetic interference tests 

• Landing impact tests (drops from test stand) 

• Air-drop tests for the landing system (from 
aircraft) 

• Water stability tests 

• Water recovery tests 

• Crew operations evaluations 

• Docking mechanism tests 

» Integrated crew module tests 

• Shuttle cargo integration 

• Orbital flight test 

The following hardware for the development and 
test program was included in the estimate 
(including spares): 

• At least two equivalent units for each 
subsystem 

• 6 crew module structural prototypes 
("boilerplates") 

• 1 crew module mockup for operations 
evaluations 


A conceptual design was developed for a 
spacecraft which could provide rescue capability 
for the International Space Station. The features 
of this vehicle which make it attractive as a 
simple rescue vehicle are: 

• use of the proven Apollo re-entry vehicle shape 
which reduces the need for extensive 
aerodynamic analysis and testing 

• increased volume with the capacity for up to 
eight people while also accommodating all 
support systems within the crew module 

• elimination of a separate, expendable service 
module which greatly reduces the number and 
complexity of interfaces and permits the 
selection of landing sites without concern about 
service module debris impact 

• separate docking adapter which allows for 
flexibility in the allocation of docking ports for 
the rescue vehicle without forcing a vehicle or 
Station design change and also allows for 
return and reuse of the expensive docking 
mechanism 

• payload bay support system which allows for 
delivery and return of the rescue vehicle with 
minimal impact on other Shuttle cargo 
operations 

Based on the engineering plan completed as 
part of the design study, development and 
fabrication of the vehicle as an in-house project 
at the Johnson Space Center appears feasible. 
The skills required have been identified and are 
available within the existing workforce at the 
Center. The fabrication techniques required are 
within the capabilities of the Center and the 
facilities and equipment are generally available. 
The actual availability of personnel for such a 
future project is difficult to predict since it 
depends on the level of support required for 
other on-going programs. However, the in- 
house approach should minimize the overall 
manpower required to complete this project. In 
comparison to the traditional NASA contracting 
approach, significant cost savings are expected 
with the in-house approach proposed in this 
study since much of the labor for procurement, 
contract management, and technical oversight is 
eliminated. Alternatively, the design concept 
would also be compatible with a fixed-price 
procurement approach. 

In addition to serving as a Space Station rescue 
vehicle, the spacecraft concept described in this 
paper could be evolved for other applications 
such as a two-way Earth-to-orbit crew transport, 
an unmanned logistics carrier, or a re-entry 
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capsule for lunar and planetary spacecraft. The 
design was based on the use of current 
technology systems and so there is great 
potential for improving the design by introducing 
more advanced systems in the future. 
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Figure 1 : Cutaway View of Rescue Vehicle 
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Figure 2: Rescue Vehicle with Dimensions (Docking Adapter not included) 
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Figure 3: Rescue Vehicle Landing System 



simulated 
APAS docking 
mechanism 
with passive 
docking latches 
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Figure 4: Payload Bay Support Structure 
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Table 1: Rescue Vehicle Concept Mass 


Functional Area 

Crew 

Module 

Docking 

Adapter 

Shuttle 

Support 

Structure 

488 

91 

591 

Thermal Protection 

861 



Propulsion 

136 



Power 

884 



Control 

91 



Avionics 

475 



Environment 

339 


23 

Landing & Pyros 

' 449 

365 

523 

Crew Accommodations 

! 436 



Weight Growth 

624 







DRY MASS (kg) 

4783 

456 

1137 





Cargo 

0 



Crew & Provisions 

1240 







INERT MASS (kg) 

6023 

456 

1137 





02, N2, Water. LiOH 

105 



Propellant 

308 







GROSS MASS (kg) 

6436 

456 

1137 





I Total mass to launch in Shuttle 


8029 kg 
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Abstract 


The paper discusses the 
development process of the 
International Space Station Alpha 
(ISSA) Integrated Traffic Model 
which is a subsystem analyses tool 
utilized in the ISSA design analysis 
cycles. Fast-track prototyping of the 
detailed relationships between daily 
crew and station consumables, 
propellant needs, maintenance 
requirements and crew rotation via 
spread sheets provide adequate bench 
marks to assess cargo vehicle design 
and performance characteristics. 

Nomenclature 


APCU 

Auxiliary Power Control 
Unit 

ATV 

Automated Transfer 
Vehicle 

CAP 

Capability 

CV 

Cargo Vehicle 

COIS 

Commercial off-the- 
shelf software 

ECLSS 

Environmental Control 
and Life Support System 

ESA 

European Space Agency 

EXT_AL 

Weight of external 
airlock 

FSE 

Flight Support 
Equipment 

JSC 

Johnson Space Center 

H 2 O 

Water 

IPT 

Integrated Product Team 

ISSA 

International Space 
Station Alpha 

kg 

Kilogram 

Max 

Maximum 

micro-g 

Micro Gravity 

MPLM 

Mini Pressurized 
Logistics Carrier 

nmi 

nautical miles 

OIU 

Orbiter Interface Unit 

ORU 

Orbital Replacement 
Unit 


PRLAs 

Prop 

ROEU 

RSA 

TIM 

SRCKLD 

STS_BASE 


STS RES 


STWRCK 

SUM 

ULC 

ULC_ATT 

USOS 


- 0 3 720 7 

Payload Retention Latch ' 

Assembly 

Propellant 

Remotely Operated 

Electrical Umbilical 

Russian Space Agency 

Technical Interchange 

Meeting 

Stowage Rack Load 
Factor 

Upmass capability of 
Shuttle at 230 nmi 
rendezvous altitude 
Space Station Program 
Office estimated 
management reserve 
for post assembly phase 
Stowage Rack 
Summation 

Unpressurized Logistic 
Carriers 

Weight of ORU interface 
attachment hardware 
United States On-orbit 
Segment 


I. Background 


Copyright c 1994 by the American Institute of 
Aeronautics and Astronautics, Inc. All Rights 
reserved. 


The approach discussed in this 
paper presents the development 
process and resultant relationships 
employed in the ISSA Integrated 
Traffic Model*. 

The Traffic Model identifies all 
vehicles docking to and departing 
from the ISSA. It characterizes 
traffic density patterns, upmass 
requirements for the ISSA, 
capabilities of cargo vehicles (CV) 
delivering those requirements, and 
propellant usage. 

The initial development of the 
Traffic Model capitalized on the 
Integrated Product Team (IPT) 
processes put in place at the Johnson 
Space Center. Continual 
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enhancements to the Traffic Model is 
streamlined by the very same 
processes. 

This paper will first discuss the 
development process followed by a 
detailed discussion of the key 
relationships that are required to 
work together to allow a traffic model 
to be successfully constructed. 

The traffic model considers: the 
Russian Space Agency (RSA) 
provided Progress-M, Progress-M2 t 
and Soyuz-TM; the European Space 
Agency (ESA) provided Automated 
Transfer Vehicle (ATV) ¥ ; and, the 
Space Shuttle as Cargo Vehicle 
candidates *. 

Input data used by the ISSA 
Traffic Model is still under 
development. Results shown in this 
paper should be considered 
preliminary and subject to change. 

The initial tooling of the ISSA 


planning base for the traffic model 
by defining their requirements in 
areas such as logistics, Flight Crew 
System resupply, and Environmental 
Control and Life Support System 
(ECLSS) resupply. Other items which 
include altitude and propellant 
strategies provide necessary inputs to 
the traffic model. 

The altitude and propellant 
requirements like the logistics and 
maintenance requirements are 
derived from ISSA subsystem and 
analysis tools that take into 
consideration all required technical 
aspects of the ISSA design. The data 
these tools provide are the key 
drivers to the Traffic Model. The 
altitude and propellant numbers 
become highly interactive with the 
maturity of the model development, 
as vehicle launch dates change so do 
the rendezvous altitudes and ISSA 
propellant requirements. The 
analytical processes and tools used to 
derive these data are not discussed in 
this paper. 



The unmodified Soyuz-TM will provide crew rescue operations through the Assembly Phase. 
Crew candidates must fit the Soyuz-TM anthropomorphic profile. 


Figure I. 1999 Assembly Year Traffic Density for ISSA 


Traffic Model was done on Micro Soft 
Excel in the Macintosh format * 

II. Traffic Model Development 

Each IPT, as part of their on- 
going design work, established the 


Figure I shows the assembly 
phase traffic patterns / density 
profile for the year 1999#. As can be 
seen by Figure I traffic to the station 
is evenly spread throughout the year. 
February shows the most amount of 
traffic with a Russian assembly flight 
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(6R), a US Utilization Flight (UF-1) 
delivering the first set of science 
experiments, and a Russian Soyuz 
flight rotating up to three (3) station 
crew memberstt, 

RSA data used in the ISSA Traffic 
Model is derived from Russian 
technical reports and information 
documented in protocols from US and 
RSA Technical Interchange Meetings 

t. 

A primary object of the ISSA 
Traffic model is to project total station 
consumable rates. This is required in 
order to identify loading effects on 
cargo vehicles and to set up the 
initial architecture of the model. 
Loading of any cargo vehicle (CV) is 
determined by examining the 
duration of stay on orbit and when 
the next CV is scheduled to arrive. 
Consumables are identified as 
propellant, gases, water, and crew 
supplies 1 * 

Another primary objective of 
the traffic model was the ability to 
maintain a status of cargo vehicle 
propellant loading over time. A CVs 
ability to meet ISSA propellant 
requirements are paramount to the 
success of the ISSA. In that light the 
ISSA Traffic Model must maintain a 
profile of on-board propellant 
storage of not only the CV but also the 
ISSA storage tanks plus keeping track 
of propellant requirements status. 
This requires keeping track of the 
total on-board propellant load while 
continually comparing it to the 
contingency propellant storage 
requirements for the ISSA. 

The science requirement for 
micro gravity constitutes the third 
objective of the traffic model. 

The ISSA must be flown such 
that once fully assembled some 


selected areas on-board must meet a .2 
micro gravity perpendicular 

component to orbital average quasi- 
static acceleration vector. This 
environment must be not be 
disturbed for at least 180 days per 
year in no less than 30 day 
increments. The micro-gravity 
requirement profiles the docking 
windows for all vehicles going to and 
returning from ISSA, opportunities 
for reboosting the station to maintain 

its operational orbit, and 
maintenance periods that would 
impact the stations micro gravity 
environment. 

A micro gravity mission profile 
was identified for planning 

guidelines which allows for eight (8) 
30 day micro-g periods per year, 
refer to Figure II, Concept of 

Operations and Utilization increment 
definition profile 1^. 


IT. RSA Kev T raffic Model 
Relationships 

Since the ISSA crew members 
will be using the cargo vehicle as a 
storage location for the supplies they 
carry, the loading of water, gases, 
propellant and crew supplies must be 
based on how long the vehicle will be 
attached to the station. 

The traffic model considers the 
use rate of each of the consumables, 
while the vehicle is attached to the 
station, in determining the correct 
CV load factors. 

To establish the relationships 
between the consumables and the 
loading factors of CVs simple 
equations have been developed. For 
these relationships "if/then" 
expressions are used. 
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An "if/then" statement is 

defined as a calculation or expression 
that is dependent on a binary 

condition or conditions. The storage 
of water considers: 

IF(SUM(H20) > CV Capability, CV CAP, 

SUM (H2O)) 

Where as: if the sum of the water 
required during the stay time of the 
cargo vehicle is greater than the CVs 
water tanks then the amount of water 
assigned to that CV is full water tanks. 
If not, then the amount of water the 
CV is to carry is the amount required. 

The SUM(H20) is determined by 
calculating the consumable rate of 
water from the date that cargo 
vehicle docked to the date the next 
cargo vehicle docks. This expression 
not only allows a comparison of 
requirements and cargo vehicle 
capabilities, but also the ability to 
assess different cargo vehicles and 
changes in capacity designs. This 
same relationship applies to the CVs 
ability to carry gases (Nitrogen, 
Oxygen or a combination of both). 

In modeling the operational 
phase of the ISSA the Traffic Model 


assigns the highest priority to crew 
supplies, then water and gases, 
followed by maintenance logistics. 
Any remaining upmass capability is 
assigned to transport propellant and 
then to the Experiments. The 
optimization of CV loading is 
currently adjusted manually, but this 
task is a candidate for automation on 
future ISSA Traffic Model upgrades. 

Propellant loading for the CV is 
determined by the following 
expression: 

IF (CV Max Cap - (CV Base + (230- 
docking altitude) * CV Orbit 
penalties) - SUM (CV Load) > = CV Prop 
Cap), CV Prop Cap, CV Max Cap - ( CV 
Base + (230-docking altitude) * CV 

Orbit penalties) - SUM (CV Load)) 

This expression considers the CV 
type as a variable, the payload 
capability of the CV, what has already 
been loaded, the maximum capacity 
for propellant, and upmass penalties 
associated with docking altitudes. 

Since the basic load of the CV is 
calculated from consumption rates 
and duration on-orbit the massaging 
of docking and departure dates 
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preserve the necessary loading 

relationships. 

One of the key factors in CV 
propellant loading is the relationship 
between propellant available on orbit 
in both the CV and the station 

elements to the propellant required 
during the period the CV will be at 
the station. 

This relationship is continually 
maintained by first keeping track of 
the propellant within the Service 
Module, Storage Tank Module (FGB 
Module), and the attached cargo 
vehicle. Then comparing it to on- 

board propellant requirements at 
specified events (vehicle docking / 

departures, reboosts, etc.). The 
traffic model alerts the user when 
any event results in a negative 
propellant margin. 

Another aspect of the ISSA 
Traffic Model is the volumetric 
loading assessment. An average of 
200 kg / Cubic Meter is used for all 
RSA pressurized cargo *>t.¥ When 
this loading results in exceeding the 
capability of the CV an indicator 
alerts the user of the violation. 


is removed and attached to a common 
berthing mechanism where it will 
remain as the crew removes and 
replaces cargo. 


Scenario number two is a 
dedicated unpressurized Space Shuttle 
mission where up to approximately 
26,000 lbs (11,794 kg's) of 
unpressurized cargo is transported 
on two (2) Unpressurized Logistic 
Carriers (ULC) to and from the space 
station. The ULC is structure that can 
allow multiple and various sized 
unpressurized elements to be 
delivered and returned in the payload 
bay of the Space Shuttle. 


Space Shuttle Scenario #1 - 

Pressurized Cargo Flight: 


In the first scenario the traffic 
model algorithms calculate the 
capability of the MPLM to carry 
cargo to the station by the following 
expression: 


(STS_BASE + ( 230 nmi - docking 
altitude) * 100 lbs) - STS_RES - EXT_AL 
- MPLM_ATT - APCU - ROEU - MPLM - 


20 * locker_wt - OIU - 2 Shuttle crew) 


For the Space Shuttle rack 
loading coefficients are used that 
identify total rack weight, carrying 
load and volume capability. 


ILL Space Shuttle Kev 

Relationships 

The ISSA Traffic Model 
investigates two (2) types of Space 
Shuttle mission scenarios. 

The First scenario is a dedicated 
pressurized cargo mission where a 16 
rack, 20,000 lbs (9072 kg's) capacity 
mini pressurized logistics carrier 
(MPLM) is used. The MPLM is 
transported to the ISSA in the Space 
Shuttle payload bay, upon arriving it 


Where: 


STS_BASE 

Upmass capability of 
Shuttle at 230 nmi 
rendezvous altitude 

STS_RES 

Space Station Program 
Office estimated 
management reserve 
for post assembly phase 

EXT_AL 

Weight of external 
airlock 

MPLM_ATT 

Weight of MPLM 
attachment hardware 
(PRLAs) 

APCU 

Weight of APCU 

ROEU 

Weight of ROEU 

MPLM 

Weight of MPLM 

locker_wt 

Weight of 20 middeck 
lockers 

OIU 

Weight of OIU 
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The result of this equation is 
used as a basis for the cargo loading 
estimates. After assembly of the 
space station (post assembly phase) 
the traffic model assumes 40 % of the 
available upmass is reserved for 
science and 60% is reserved for crew 
supplies and space station 
maintenance logistics. 

The space station design teams 
are interested in tracking the mass 
and volume of the maintenance 
Orbital Replacement Units (ORUs) 
that can be delivered. Therefor the 
model takes into consideration the 
average amount of mass and volume 
that can be placed in a space station 
stowage rack and deducts the rack 
weight from the logistics allocation 
of upmass. This can be seen in the 
following calculation: 

IF (Shuttle upmass capability > 20000, 
IF((20000 * 0.6 - unpressurized cargo 
- crew supplies) - ((20000 * 0.6 - 

unpressurized cargo - crew supplies) 

/ SRCKLD) * STWRCK < = logistic 
upmass requirement, (20000 * 0.6 
unpressurized cargo - crew supplies) 

- ((20000 * 0.6 - unpressurized cargo - 
crew supplies) / SRCK.LD) * STWRCK, 
logistic upmass requirement), 
IF((Shuttle upmass capability * 0.6 - 
unpressurized cargo - crew supplies) 

- ((Shuttle upmass capability * 0.6 - 

unpressurized cargo - crew supplies) 

/ SRCK_LD) * STWRCK < = logistic 
upmass requirement, (Shuttle upmass 
capability * 0.6 - unpressurized cargo 

- crew supplies) - ((Shuttle upmass 
capability * 0.6 - unpressurized cargo 

- crew supplies) / SRCK_LD) * 
STWRCK, logistic upmass 
requirement))) 

Where: 

SRCK_LD Average load for a 

storage rack 

STWRCK Weight of storage rack 

The above calculation also takes 
into consideration the maximum 
capability of the MPLM and the 


upmass capability of the Space 
Shuttle at the assigned docking 
altitude. 

The spacing of Shuttle launches 
has been driven by the micro-g 
profile (Figure II) and the Space 
Station Freedom retained design 
features. 

These design features include 
the allocation of 40 % of the upmass 
to science, the number of stowage 
and refrigeration racks in the 
Habitation Module and the capacity of 
the MPLM all contribute to a 90 day 
crew supply replenishment cycle. 
Therefore as a basic scheduling 
template four (4) pressurized Shuttle 
mission launches are scheduled on 90 
day centers. A 5th Shuttle mission, 
that carries unpressurized cargo, is 
scheduled within one (1) of the 90 
day cycles. 


Space Shuttle Scenario #2 - 

Unpressurized Cargo Flight: 

The unpressurized Shuttle 
mission scenario is handled in the 
same manner as the pressurized 
scenario. Volumetric assessments are 
handled as secondary checks once 
the loading of each vehicle is 
determined. The traffic model 
calculates the Shuttle upmass 
capability with the following 
expression: 

STS_BASE + (230 nmi - docking 
altitude) * 100) - STS_RES - ULC * 2 - 
ULC_ATT*2 - PRLA * 2 - APCU - 


EXT_AL - 20 * locker_wt - OIU 

Where: 

STS_BASE 

Upmass capability of 
Shuttle at 230 nmi 


rendezvous attitude 

STS.RES 

Space Station Program 
Office estimated 


management reserve 

ULC 

for post assembly phase 
Base weight of ULC 
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MF/MC Resupply Assessment - USOS Pressurized Loglst 
upmass (based on: 9/28/94 Assembley Sequence) 



Figure III. USOS Comparison Between Pressurized Logistics 
requirements and Resupply Capabilities 


ULC_ATT 

Weight of ORU interface 
attachment hardware 

PRLA 

Weight of ULC 
attachment hardware 

EXT_AL 

Weight of external 
airlock 

APCU 

Weight of APCU 

locker_wt 

Weight of 20 middeck 
lockers 

OIU 

Weight of OIU 


For the Unpressurized Shuttle 
flight load capability the traffic 
model uses the following expression: 


IF (Science unpressurized upmass + 
Logistic Maintenance requirements > 
Shuttle upmass capability , Shuttle 
upmass capability. Science 
unpressurized upmass + Logistic 
Maintenance requirements) 


IV. Traffic Model Results 

Several outputs of the traffic 
model are used by the ISSA Program. 


The docking and undocking of 
the visiting vehicles set the basis for 
determining quiet zones from which 
micro gravity periods can be 
planned. 

The annual summaries provide 
comparisons of requirements versus 
capabilities for both the United States 
On-orbit Segment (USOS) and the 
Russian Segment. At the time of this 
paper the ISSA Traffic Model 
indicates a backlog of USOS 
pressurized logistics (refer to Figure 
III). 

The annual average mass of 
cargo delivered to the station is 
approximately 100 metric tons per 
year (includes carrier weights). 20 to 
25 metric tons are delivered to the 
Russian Segment 1 and is comprised 
of approximately eight (8) to 11 
metric tons of propellant, 6800 kg of 
crew supplies, 3.3 metric tons of 
experiment hardware, 2-3 metric tons 
of water, two (2) metric tons of 
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maintenance logistics, and 500 kg of 
gases. The US OS annual average mass 
is approximately 75 to 80 metric tons 
and is comprised of 18 to 23 metric 
tons of science, 8 metric tons of crew 
supplies, 8 to 12 metric tons of 
maintenance logistics, and 37 metric 
tons of Flight Support Equipment 
(FSE). 


Summary 

All the crew rotation logistics, 
propellant, and other supply 

requirements have been aggregates 
as the basis for defining a traffic 
model to the ISSA. 

Numerous expressions have 
been developed which allow 

definition of the various 

consumption rates and their 
relationship to each other. This has 
all been integrated in commercial off 
the shelf (COTS) software and has set 
up base rules for enhanced modeling 
through higher order expressions. 
Rapid prototyping of certain key 
design characteristics of cargo 
vehicles and ISSA capabilities allow 
for in-depth design assessments in a 
rapid changing design environment. 
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Abstract 

This paper provides an overview of what the 
primary contractors at Kennedy Space Center (KSC) 
are doing in the field of predictive engineering. The 
technologies employed by each of the contractors and 
the cost savings associated with the implementation of 
these predictive engineering methods are discussed. 
The sources include predictive engineering 
implementation plans, published by each of the 
contractors and interviews with the authors of these 
implementation plans. 

Introduction 

The primary mission of Kennedy Space 
Center is to launch Space Shuttles. Shuttle launch 
costs are comprised of manpower, material, and 
equipment. There are billions of dollars invested in 
equipment located on the Kennedy Space Center which 
is essential to launching Shuttles. This equipment 
must be in a safe and operable condition upon demand. 

However, electrical and mechanical 
equipment will gradually deteriorate over time and this 
will eventually cause the equipment to fail. The harsh 
environment that is present at KSC due to the high 
humidity, salt air and hazardous chemicals increases 
the number of equipment problems. Preventive 
maintenance is used to slow this deterioration and 
thereby extend the useful life of the equipment. 
Traditional preventive maintenance provides for 
planned shutdowns during periods of inactivity or low 
usage for major overhauls. 

Predictive engineering, a branch of preventive 
maintenance, is a method to systematically monitor 
equipment and perform operational trend analysis on a 
regularly scheduled basis to determine the condition of 
the equipment. On-line detection, trending and 
diagnostics provide an early warning of potential 
equipment failure and reduce the need for traditional 
preventive maintenance. Predictive engineering also 
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decreases unexpected breakdowns and helps to ensure 
the continuity of operation. 

r: 9 

A preventive maintenance program which 
utilizes predictive engineering methods provides 
numerous benefits including: 

Reduced maintenance downtime 
Reduced unplanned failures 
Reduced risk of induced failures 
Reduced repair costs 
Reduced manpower requirements 
Increased equipment availability 
Extended useful life of equipment 
Improved safety and reliability 

In the current environment of decreased 
funding there is a constant demand to reduce cost in all 
areas. The cost of preventive maintenance is no 
exception. The implementation of predictive 
engineering into the existing Kennedy Space Center 
preventive maintenance programs has resulted in 
significant cost savings. 

Shuttle Processing Contractor 

The Shuttle Processing Contractor (SPC) 
introduced predictive engineering in 1988 with 
Vibration Trend Analysis to address high failure rates 
of the Orbiter Processing Facility (OPF) Environmental 
Control System (ECS) Ground Support Equipment. 

The initial program of Vibration Trend Analysis 
involved 66 ECS machines from Launch Pads A and 
B, the OPF’s, and the Portable Purge Units for which 
the prime contractor has maintenance responsibility. 
SPC has stated that this program effectively reduced 
the failure rate of ECS rotating equipment and the risk 
of flight hardware damage and personnel injury. 

In 1990 a plan to continue the Vibration 
Trend Analysis program and expand predictive 
engineering was developed. This plan has been 
applied to all mechanical and electrical Ground 
Support Equipment, Facility Equipment, and to some 
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designated flight hardware. In order to accomplish 
this the Kennedy Space Center Integrated Schedule, 
which drives monitoring and data collection schedules, 
had to be revised. 

There are currently three people under the 
Shuttle Processing Contract that support over 1100 
items being monitored by predictive engineering 
methods. These technologies now include Vibration 
Trend Analysis, Ferrography Trend Analysis, 
Thermography, Ultrasonics, Ultrasound, Laser 
Alignment, Laser Shearography, and Motor Circuit 
Analysis. 

Vibration Trend Analysis evaluates the on- 
line condition of mechanical components and their 
effect on related pieces of mechanical hardware. It can 
detect, identify and isolate specific component 
degradation in bearings, gears, pulleys, blowers, fans, 
belts, and couplings. For this kind of analysis, the type 
and amount of data required will vary from one 
analysis problem to another. Fortunately, given the 
advances in microprocessors and vibration 
instrumentation, vibration analysis is an adaptive 
process where real time changes to test frequencies and 
directions can be made in order to provide more 
information. 

Ferrography Trend Analysis is analogous to a 
common blood test. This analysis uses diagnostic and 
predictive techniques to evaluate the on-line condition 
of interacting lubricated or fluid powered parts. The 
lubricants or fluids are analyzed for condition, level, 
and type of contamination. Analysis of wear particles 
can isolate a failing component, the mode of failure, 
and the estimated time to failure through trending. 
Equipment life is extended by oil analysis instead of 
depending entirely on operating hours as the driver for 
scheduled maintenance. This technology identified 
three suppliers who inadvertently shipped oil that was 
contaminated with sand and metal particles. As a 
result, a nationwide alert was issued and potential 
damage to the KSC elevator and crane systems was 
avoided. 

Thermography is the science of detecting 
temperature differences by scanning infrared 
emissions. It is used to analyze equipment that 
exhibits thermal discrepancies prior to failure or when 
not operating properly. This includes equipment as 
varied as electrical panels, circuit boards, pumps, 
motors and many others. There are several advantages 
to using non-contact thermal infrared measurement as 
opposed to more conventional methods of temperature 


measurement. The most commonly stated advantages 
are that it is non-intrusive, it is much quicker, and it 
can measure the temperature at the surface of the 
equipment. The infrared camera effectively detected a 
defective fuse at one of the KSC electrical switchyards. 
If conventional preventive maintenance methods had 
been used instead, the arcing would have gone 
undetected. This would have caused emergency power 
to be activated and could have resulted in a possible 
launch delay. 

Ultrasonics technology detects hidden flaws in 
materials, especially metals. It also verifies weld joints 
and fluid levels by monitoring the high frequency 
sound generated by the turbulent or restricted flow of 
escaping gasses. This technology has advanced into a 
completely digital and portable microprocessor 
controlled ultrasonic flaw detector. It is safer and 
faster than current X-ray technology. 

Ultrasound is an acoustical detection system 
that detects sound waves generated by a component 
and transmitted through some type of medium. This 
medium can be air, water, or organic or inorganic 
material. It is a technology which primarily detects 
leaks involving all types of fluids. Equipment such as 
gearboxes, compressors, relief valves, boilers, and tube 
banks can be easily inspected using ultrasound. 

Laser Alignment is the newest predictive 
engineering method to be employed in the alignment of 
rotating systems. It detects misalignment in 
mechanical equipment, which places undue force on 
bearings, and can lead to accelerated wear or possible 
catastrophic failure. It verifies proper installation and 
even fabrication of mechanical systems prior to 
operation. It also monitors proper alignment during 
equipment operation. Correct alignment has been 
credited with saving as much as ten percent on power 
consumption. 

Laser Shearography is a form of 
nondestructive testing for general purpose strain 
analysis and inspection of metallic or composite 
materials. It is particularly useful for detecting 
corrosion, which can go unnoticed during a typical 
visual inspection. Laser Shearography has many 
applications at KSC, principally in detecting 
debonding of composite structures on the Orbiter, the 
External Tank, and the Solid Rocket Boosters. 

Motor Circuit Analysis determines the level of 
degradation in electrical motor circuits such as 
individual phase resistance from the power bus 
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disconnect through the motor windings, phase to 
ground resistance, inductance of the motor coils and 
capacitance of each of the three phases to ground. 
Detecting and correcting a 4.5% phase imbalance saves 
25% in additional power consumption and can double 
the useful life of the motor. Considering that SPC 
engineers believe that most of the three phase motors 
in operation today are out of balance, this is one area 
where enormous cost savings are anticipated at KSC. 

Through the use of these eight preventive 
engineering methods the contractor was able to save 
approximately two million dollars last year alone. 
Some of these technologies have exhibited very high 
cost paybacks. The Shuttle Processing Contractor 
believes that this type of program has and will continue 
to save lives, extend the useful life of equipment, and 
increase equipment availability in order to insure 
operational success. 

Pavload Ground Operations Contractor 

The Payload Ground Operations Contractor 
(PGOC) began incorporating predictive engineering 
methods into their preventive maintenance program 
with the use of Vibration Analysis in 1988 and 
Ferrography in 1989. In 1992 they began focusing on 
a reliability centered maintenance program. Systems 
engineers reviewed the list of equipment Preventive 
Maintenance Instructions (PMI) and provided 
suggestions as to what requirements were needed in 
order to utilize predictive engineering technologies 
which would result in a more efficient and reliable 
approach to maintenance. They then rewrote selected 
PMTs and added documentation to incorporate 
Vibration Analysis, Thermography, Ferrography, 
Ultrasonic Monitoring, and Laser Alignment. 

The Payload Ground Operations Contractor 
has now established a complete reliability centered 
maintenance plan which combines predictive 
technologies with preventive maintenance procedures. 
Five basic questions are addressed to determine the 
amount of maintenance required for each piece of 
equipment: 

1. What does the equipment do? 

2. What failures occur? 

3. What are the consequences of the failures? 

4. How can the failures be prevented? 

5. What is the cost benefit of maintenance versus 
failure. 


In addition, criteria for predictive 
maintenance depends on the type of equipment, how it 
is used, and the mission criticality or safety aspects of 
that use. Identical pieces of equipment can have 
dissimilar maintenance requirements in different 
applications. As a result of this, four distinct levels of 
maintenance were identified. 

The Level I maintenance procedure is for 
equipment that requires no maintenance. The 
hardware is run to failure and then repaired. The 
reason for this is that the cost of replacing or repairing 
the equipment is less than the cost of maintenance. It 
should also be noted that this level of maintenance only 
applies to non-critical systems where consequences of 
failure do not impact safety. 

The Level n maintenance procedure specifies 
that only the maintenance which is required by KSC 
regulations will be performed. In some cases, since 
this is still non-critical equipment, a waiver to the 
regulations will be processed to reduce the amount of 
maintenance that must be done. Equipment within this 
category may require some predictive maintenance, but 
it is usually hardware that can be shut down for 
extended periods of time for repair or preventive 
maintenance. 

Equipment that falls under the Level III 
maintenance category are items where the amount of 
preventive maintenance has been reduced and 
predictive technologies are being utilized to monitor 
and trend any potential problems. 

The Level IV category is for those items that 
require full maintenance, both preventive and 
predictive, to avert functional failures. These are 
critical items, where a single failure could result in the 
loss of life or damage to flight hardware. Hardware is 
also designated Level IV if it monitors hazardous 
operations and where safety is a major concern. 

As noted earlier, the PGOC has focused on 
rewriting the PMTs to incorporate predictive 
engineering technologies into these documents and as a 
result they measure their cost savings in terms of man- 
hours. In fiscal year 1994 alone, they saved 
approximately 12,000 man-hours through the 
implementation of predictive maintenance methods in 
place of traditional preventive maintenance. A large 
portion of these savings came from changing the PMTs 
for the Heating, Ventilation, and Air Conditioning 
units, which include all facility boilers and pumps, 
along with the compressed air and vacuum systems. 
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This has been accomplished with a staff of two 
engineers who perform predictive analysis and 
trending on 185 pieces of equipment. The amount of 
equipment tested using predictive technologies is 
anticipated to increase during the next year with the 
addition of the Space Station Ground Support 
Equipment and facility hardware. 

Base Operation s Contractor 

The Base Operations Contractor (BOC) 
maintenance program is a reliability centered 
maintenance philosophy that incorporates preventive, 
predictive, and proactive maintenance with equipment 
life cycle management. This results in minimizing 
equipment failures that could impact critical KSC 
systems and accomplishment of required maintenance 
in the most cost effective manner. The BOC uses 
predictive engineering as a means to complement their 
preventive maintenance program. 

Their approach to predictive engineering is 
similar to that of the payloads contractor. They do not 
attempt to apply predictive engineering methods to all 
their systems. When the predictive engineering plan 
was first established, all of the equipment was assessed 
based on operational criticality. The following 
parameters determine these criticalities: 

Safety 

Mission 

Environmental 

Cost of Maintenance/Replacement 

The Base Operations Contractor is responsible 
for 32,000 pieces of equipment. They currently 
monitor 51% of the two thousand pieces of equipment 
that have been targeted for predictive analysis. This 
has been accomplished with a staff of two engineers. 
They have also developed a detailed data base to keep 
track of equipment, failures, and savings associated 
with the implementation of the predictive engineering 
methods. 

In addition to the technologies discussed 
previously, the BOC also utilizes several different 
predictive maintenance methods, including Megger 
Testing, Power Factor Testing, Breaker Timing 
Testing, Contact Resistance, Insulation Oil Analysis, 
Gas-In-Oil Analysis, Impedance Testing, and Hi-Pot 
Testing. 

Megger Testing is primarily used on 
transformers, circuit breakers, and switch gears. This 


is a direct current test where a voltage is applied to the 
equipment in order to determine insulation resistance 
and monitor trends. 

Power Factor Testing is basically a power loss 
measurement. It is a non-destructive alternating 
current test that shows the condition of the insulation. 
When the circuit impedance changes due to aging, 
moisture, contamination, insulation shorts, or damage, 
the power factor will increase. The BOC engineers 
believe that this is one of the most useful predictive 
engineering tests for transformers, circuit breakers, and 
switch gears. 

Breaker Timing Testing is a mechanical test 
which displays the speed and position of breaker 
contacts before, during , and after an operation. It is 
used to trend information on medium or high voltage 
breakers in order to determine if adjustments need to 
be made to the breaker operating mechanism. 

Oil Analysis is used on high voltage 
transformers, circuit breakers and medium voltage 
switches where oil is supplied as an insulator. 
Performing this analysis on the electrical insulating oil 
provides a great deal of information about the 
operational history and current condition of the 
equipment. Any type of heating, arcing, or coagulation 
produces by-products that can be detected in the 
insulation oil. 

Gas-In-Oil Analysis is one of the best 
predictive engineering tests for transformers that use 
oil insulation according to BOC engineers. By 
analyzing a small sample of oil to determine what 
gases are present, failure and degradation patterns 
internal to the transformer are be identified. This 
predictive engineering technology was successfully 
identified acetylene in the insulation oil in one of the 
substations. Since acetylene is normally not present 
unless there has been arcing, a critical problem was 
recognized and corrected prior to failure. 

Impedance Testing is used to trend the 
internal impedance of batteiy cells. Since this 
impedance is directly related to the remaining capacity 
of the battery, it projects battery end-of-life or cell 
degradation. 

Hi-Pot Testing is a technology used primarily 
on cables and switches. It is a direct current, high 
voltage test that detects excessive leakage current. It is 
used for testing new equipment and also to trend the 
degradation of equipment in use. However, Hi-Pot has 
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the potential be a destructive test, so it is not a common Preventive and Predictive Maintenance Levels R C M 

predictive maintenance tool. In many cases Power Decision Tree, Ron Gawlik 

Factor Testing replaces Hi-Pot Testing for high voltage 

cables. Hi-Pot Testing is then used only when the 

insulation condition has reached a questionable 

threshold. 

Through the use of these predictive 
engineering technologies the Base Operations 
Contractor has realized almost one million dollars in 
cost savings over the past two years. The investment 
in the predictive maintenance program thus far has 
been minimal. Approximately $450K has been spent 
on equipment and salaries. The BOC anticipates that 
this program will save ten million dollars within the 
next ten years. 


Conclusion 

It is evident that there are numerous 
predictive technologies that indicate machine health 
and provide critical information about the operational 
condition of equipment. Through effective utilization 
of these predictive engineering methods, the amount 
of preventive maintenance required to support critical 
systems has been reduced, resulting in considerable 
manpower savings. The implementation of predictive 
engineering technologies also provides an early 
indication of potential problems. Therefore, significant 
cost savings have been and will continue to be achieved 
through the reduction of downtime due to failures and 
scheduled maintenance, and extended hardware life. 
In addition to the long term cost savings, an increase in 
the overall reliability of the systems at KSC will 
continue to be realized. 
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Abstract 


The objective of this publication is to 
introduce the enhancement methods for the overall 
reliability and maintainability methods of 
assessment on the International Space Station. It 
is essential that the process to predict the values of 
the maintenance time dependent variable 
parameters such as MTBF over time do not in 
themselves generate uncontrolled deviation in the 
results of the ILS analysis such as Life Cycle Cost, 
spares calculation, etc. Furthermore, the very acute 
problems of micrometeorite, Cosmic rays, flares, 
atomic oxygen, ionization effects, orbital plumes 
and all the other factors that differentiate 
maintainable space operations from non 
maintainable space operations and/or ground 
operations must be accounted for. Therefore, 
these parameters need be subjected to a special 
and complex process. Since reliability and 
maintainability strongly depends on the operating 
conditions that are encountered during the entire 
life of the International Space Station, it is important 
that such conditions are accurately identified at the 
beginning of the Logistics Support requirements 
process. Environmental conditions which exert a 


strong influence on International Space Station will 
be discussed in this report. Concurrent (combined) 
space environments may be more detrimental to 
the reliability and maintainability of the International 
Space Station than the effects of a single 
environment. In characterizing the logistics support 
requirements process, the developed design/test 
criteria must consider both the single and/or 
combined environments in anticipation of providing 
hardware capability to withstand the hazards of the 
International Space Station profile. The effects of 
the combined environments (typical) in a matrix 
relationship on the International Space Station will 
be shown. The combinations of the environments 
where the total effect is more damaging than the 
cumulative effects of the environments acting 
singly, may include a combination such as 
temperature, humidity, altitude, shock, and vibration 
while an item is being transported. The item’s 
acceptance to its end-of-life sequence must be 
examined for these effects. 
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1. REFERENCES 

A. Space station freedom external 
maintenance task team, July 1 990, 
final report; and 

B. External maintenance solution 
team, January 1991, final report. 


2. OBJECTIVE 

2.1 The objective of this report is to note the 
environmental factors in a space environment 
which must be accounted for in order to accurately 
forecast the maintenance time dependent variables 
(e g: MTBF). 


3. INTRODUCTION 

3.1 In response to Reference A task, a series 
of three (3) reports which describe the initial 
approach to conduct refinement processes for the 
maintenance time dependent parameters such as 
MTBF in order to accurately forecast the Logistics 
Support requirements were completed. This report 
is the first of the three reports. The paramount and 
complex problem relative to the time dependent 
maintenance variable parameters became apparent 
as a result of the investigations performed on the 
RAM packages. 

3.2 The process to predict the values of the 
maintenance time dependent variable parameters 
such as MTBF over time, as report 1 and annex A 
of report 2 (this report is labelled as: 
"INTEGRATED LOGISTICS SUPPORT ANALYSIS 
OF THE INTERNATIONAL SPACE STATION, 
BACKGROUND AND SUMMARY OF 
MATHEMATICAL MODELLING & FAILURE 
DENSITY DISTRIBUTIONS PERTAINING TO 
MAINTENANCE TIME DEPENDENT 
PARAMETERS", and is published in this 
symposium) elucidate, must be treated by a 
complex process to prevent uncontrolled deviation 
in the results of the ILS analysis such as Life Cycle 
Cost, spares calculation, etc. Furthermore, the very 
acute problems of micrometeorites, Cosmic rays, 
flares, atomic oxygen, ionization effects, orbital 
plumes and all the other factors that differentiate 
maintainable space operations from non 
maintainable space operations and/or ground 


operations need to be accounted for. Therefore, 
these parameters need be subjected to a special 
and complex process. 

4. E NVIRONMENTAL FACTORS 

4.1 Since reliability and maintainability strongly 

depends on the operating conditions that are 
encountered during the entire life of the MSS, it is 
important that such conditions are accurately 
identified at the beginning of the Logistics Support 
requirements process. Environmental conditions 
which exert a strong influence on MSS are included 
in table 4.1 which provides a typical checklist for 
space environmental coverage. Concurrent 
(combined) space environments may be more 
detrimental to the reliability and maintainability of 
the MSS than the effects of a single environment. 
In characterizing the logistics support requirements 
process, the developed design/test criteria must 
consider both the single and/or combined 
environments in anticipation of providing hardware 
capability to withstand the hazards of the MSS 
profile. Figure 4.1 illustrates the effects of 

combined environments (typical) in a matrix 
relationship. It shows the combinations where the 
total effect is more damaging than the cumulative 
effects of the environments acting singly, may 
include a combination such as temperature, 
humidity, altitude, shock, and vibration while an 
item is being transported. The items's acceptance 
to its end-of-life sequence must be examined for 
these effects. Table 4.2 illustrates the 
environmental effects on the MSS. 
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TABLE 4.1: ENVIRONMENTAL COVERAGE CHECKLIST (TYPICAL) 


NATURAL 

INDUCED 

Geomagnetism 

Radiation, Electromagnetic 

Gravity, low 

Radiation, Nuclear 

Ionized Gases 

Shock 

Meteorites 

Temperature, High, Aero. Heating 

Pressure, Low 

Temperature, Low, Aero. Cooling 

Pressure, High 

Vibration, Mechanical 

Radiation, Cosmic, Solar 

Vibration, Acoustic 

Radiation, Electromagnetic 


Temperature, High 


Temperature, Low 
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FIGURE 4.1: EFFECT OF COMBINED ENVIRONMENTS 



: atigue Interference with function; 

Increased wear; 

Structural collapse. 
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Magnetic field Induced magnetization Interference with function; 

Alteration of electrical properties; 
Induced heating. 


4.3 Low temperatures experienced by the 
electronic equipment can also cause reliability and 
maintainability problems. These problems are 
usually associated with mechanical elements of the 
system. They include mechanical stresses 
produced by differences in the coefficients of 
expansion (contraction) of metallic and nonmetallic 
materials, embrittlement of non metallic 
components, mechanical forces caused by freezing 
of entrapped moisture, stiffening of liquid 
constituents, etc. Typical examples include 
cracking of seams, binding of mechanical linkages, 
and excessive viscosity of lubricants. 

4.4 Additional stresses are produced when 
electronic equipment is exposed to sudden 
changes of temperature or rapidly changing 
temperature cycling conditions. These conditions 
generate large internal mechanical stresses in 
structural elements, particularly when dissimilar 
materials are involved. Effects of the thermal shock 
induced stresses include cracking of seams, 
delamination, loss of hermiticity, leakage of fill 
gases, separation of encapsulating components 
from components and enclosure surface leading to 
the creation of voids, and distortion of support 
members. 

4.5 Electronic equipment is often expected to 
be subject to environmental shock and vibration 
both during normal use and testing. Such 
environments can cause physical damage to parts 
and structural members when deflections produced 
cause mechanical stresses which exceed the 
allowable working stress of the constituent parts. 

4.6 The natural frequencies of items comprising 
the MSS are important parameters which must be 
considered in the logistics support of the MSS 
since a resonant condition can be produced if a 
natural frequency is within the vibration frequency 
range. The resonance condition will greatly amplify 
the deflection of the subsystem and may increase 
stresses beyond the safe limit. 

4.7 The vibration environment can be 
particularly severe for electrical connectors on the 
MSS, since it may cause relative motion between 
members of the connector. This motion, in 
combination with other environmental stresses, can 
produce fret corrosion. This generates wear debris 
and cause large variations in contact resistance. 


4.8 High energy radiation can also cause 
ionization effects which degrade the insulation 
levels of dielectric materials. The environmental 
factors that will be experienced by the MSS in its 
total life cycle requires consideration in the logistics 
support requirement process. This assures that 
adequate provisions are made for effective MSS 
logistic support requirements. 

4.9 In the environmental stress identification 
process that precedes the selection of 
environmental strength techniques, it is essential 
that stresses associated with all life intervals of the 
MSS be considered. This includes not only the 
operational and maintenance environments, but 
also the pre operational environments, when 
stresses imposed on the parts during the 
manufacturing assembly, inspection, testing, 
shipping, and installation may have significant 
impact on the eventual availability of the MSS. 
Stresses imposed during the pre operational phase 
are often overlooked. They may, however, 
represent a particularly harsh environment which 
MSS must withstand. Often, the environments to 
which MSS is exposed during shipping and 
installation are more severe than those MSS will 
encounter under normal operating conditions. It is 
also probable that some of the environmental 
strength features that are contained in the MSS 
system design pertain to conditions that are 
encountered in the pre operational phase, and not 
in conditions that the equipment experiences after 
being put into its orbit (i.e. infant mortality and/or 
latent failures). 

4.10 Reference A and B indicate that some of 
the requirements such as the provisions for 
oxidation, etc have been accounted for as part of 
the K factors. Our analysis of the K factors, the 
program’s RAM data packages as well as Ref. A 
and B of indicate the opposite. The failure rates 
need to be predicted by following a consistent 
approach which will account for all factors existent 
in a space environment. 

4.11 This consistent approach should include but 
not be limited to the following: 

A. Utilization of constant failure rates 
(i.e. as report 2 indicate, different 
family of ORUs belong to different 
failure distribution). To universally 
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B. 


calculate the failure rates using 
exponential failure distribution is an 
incorrect method for predicting 
time dependent maintenance 
parameters; 

Ref. B assigns weibull distribution 
for the life limit items, lognormal for 
MTTR calculation and exponential 
for the random failures. This 
assignment is not accurate and 
such assignments should be 
substantiated (please refer to 
report 2); 


C. Ref. A and B take the increase of 
the failure rate due to duty cycle 
granted. This is not true due to 
the fact that items such as battery 
of a car need be used in order to 
avoid built up of the chemicals at 
the contacts interface; 


D. 



NPRD has been used as a basis 
for comparison for estimating the 
failure rates. This similiarization at 
the CDR level is perceived as 
rudimentary due to the absence of 
any lay out in the NPRD thereby 
incurring tremendous inaccuracy 
for the results; 


E. 



F. 


The K factors used by reference A 
and B does not include the 
preventive maintenance, inspection 
and accurate overhead cost. 
Furthermore, MSS is the first 
maintainable space operation of its 
kind and utilization of engineering 
judgement to determine K factors 
for this maintainable space 
operation is not valid. Utilization of 
previous spacecraft anomalies, as 
supportive data, is encouraged in 
parallel with accurate stochastical 
and analytical techniques which 
incorporate all the different space 
environments such as cosmic rays, 
flares, micrometeorites, etc; 

In addition, the following areas 
need to be accounted for: 


a. 

b. 

c. 

d. 

e. 


f. 

g- 

h. 

i. 


Common mode failures; 
Common cause failures; 
Maintenance/Operations 
induced failures; 

Life limited items; 

Duty cycle (i.e. duty cycle 
does not necessarily 
increase failure rates); 
Construction induced 
failures; 

micrometeorites, atomic 
oxygen, flares, cosmic 
rays; 

Advances in technology; 

and 

Etc. 
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The International Space Station 
Alpha (ISSA) End-to-End On-Orbit 
Maintenance Process Flow 


Kenneth W. Zingrebe, II 
Barrios Technology, Inc. 
Houston, Texas 


As a tool for construction and 
refinement of the on-orbit 
maintenance system to sustain the 
ISSA, the Mission Operations 
Directorate (MOD) developed an end- 
to-end on-orbit maintenance process 
flow. This paper discusses and 
demonstrates that process flow. This 
tool is being used by MOD to 
identify areas which require further 
work in preparation for MOD'S role 
in the conduct of on-orbit 
maintenance operations. 


To fit this paper to the page length 
limitations much of the detail of 1.2 
Perform Pre Maintenance 
Activities, 1.3 - Perform 

Maintenance Activity, 1.4 - Perform 
Post Maintenance Activities, and the 
Input and Output definitions (N1 to 
N32) have been eliminated. The 
process associated with 1.1 
Maintenance Definition and Planning 
is of greater interest and of most 
importance to the success of on-orbit 
maintenance operations. If the 
details of the latter part of the paper 
are desired by any reader the author 
will be glad to provide them . 

1 .1 - Maintenance Definition 
and Planning 


1 .2- Perform Pre Maintenance 
Activities 


1 .3 - Perform Maintenance 
Activity 


1 .4 - Perform Post 
Maintenance Activities 


1.1 - Maintenance Definition and 

Planning: This process is the 

tactical method that takes the 


declared failed item to the stage 
where the resources are available to 
do the task and task execution is 
imminent. Sub processes are: 

• Determine which type of 
maintenance task is appropriate (IVA, 
EVA, EVR, etc..) (Corrective, 
Preventive, etc..) 

-Ensure that a basic maintenance 
procedure exists. 

•Assure that the resources to perform 
the task are available on-orbit 
(including approved procedures, 
spares, crew time, tools, etc..) 
-Determine where this task falls in 
the backlog and work to evaluate and 
schedule the task. 



1.1.1 - Identify and Log Maintenance 

Task: Formal statement that a 

system component is failed. The 
component may be an Orbital 
Replacement Unit (ORU), structure, 
cable, fluid line, etc. Determine if 
the hardware is IVA, EVA, NASA, 
NAS DA, RS A, ESA, or CSA. 
Identify the most efficient method of 
repair EVR or EVA if the task is 
external to the vehicle. The anomaly 
report is updated. 

1.1. 1.1 - Perform Isolation Using 

Maintenance: Hardware failure 

isolation that cannot be performed by 
BITE/BIT, malfunctions, telemetry, 
or other hands-off type methods may 
be performed by the crew using 
isolation/ troubleshooting procedures/ 
methods developed by ground 
controllers. 
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1.1. 1.2 - Identify the Type of 

Maintenance Task: The level of 

maintenance starts out at 
Organizational but may progress to 
Intermediate level if the complete 
ORU is not stored On-Orbit. The 
anomaly report is updated. 

1.1. 1.3 - Log the Maintenance Task: 

After the type of maintenance has 
been identified the task is logged in 
so an execution time can be 

determined though the planning 

system and then the anomaly report 
is updated. 

1.1.2 - Maintenance Activity 

Definition: The OSO compiles and 

submits the data required for 
scheduling the Maintenance Procedure 
to the Operations Planning Officer 
(Ops Planner) so it can be time-lined 
on the Crew's activity plan. Data 
includes: activity duration; 

applicable procedures; Crew and 
vehicle requirements; Vehicle/system 
constraints; and any down-link/up- 
link audio, video, or data 
requirements. 


The Ops Planner uses this 
information to integrate the 
maintenance procedure into the crew's 
activity plan. This information will 



available: This process involves how 

maintenance operator interfaces with 
the program office to obtain 
maintenance spares/supplies and 
tools/support equipment. This 

process also establishes the interface 
between the maintenance operator and 
the inventory operator for launch and 
landing manifesting of items required 
for maintenance. 
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N5.4- 





Yes 


1.1 .2.1.1 

* 

- Request 

1.1 .2.1 .2 

and 

- Request 

determine 

and 

when the 

determine 

tools/ 

when the 

support 

spares/ 

equipment 

supplies 

are 

are 

available. 

available. 



N26 - 

Information on 
the projected 
availability of 
tools/support 
equipment and 
spares/ 
supplies. 


1.1.2. 1.1 - Request and determine 

when the tools/support equipment are 
available: The maintenance operator 

contacts the inventory operator to 
determine if the tools/support 
equipment are available on-orbit. If 
the tools/support equipment are not 
available on-orbit, the maintenance 
operator requests tools/support 
equipment from the supply support 
IPT/support equipment IPT. The 
maintenance operator makes a 
manifest request to the inventory 
operator via CMILP. If the spares 
/supplies, and tools/support 
equipment are available then the pre- 


maintenance activities will be 
performed. 


The International Partners (IP) are an 
exception to this maintenance process 
flow in that they have analogous 
organizations to make spares/supplies 
and tools/support equipment 

available and they are solely 

responsible for the maintenance 

performed on their own hardware. 

1.1. 2. 2 - Determine systems 

configuration constraints & resource 
availability. 


JL i.i.i 


1.1 .2.2.1 - 


1.1 .2.2.2- 

Determine 


Determine 

Systems 


Resource 

Configuration 


Availability 

Constraints 


1 



1.1. 2. 2.1 - Determine Systems 

Configuration Constraints: The 

maintenance operator informs the 
systems operators of the time to 
perform the maintenance to determine 
if the hardware can be down for that 
period of time and coordinates the 
systems configuration to perform 
maintenance 

1.1. 2. 2. 2 - Determine Resource 

Availability: The maintenance 

operator informs the operations 
planners the resources required to do 
the maintenance and confers with 
systems operators & the operations 
planners on the impact of performing 
maintenance on resource availability. 
1. 1.2.3 - Determine level of crew 

training: The maintenance operator 

utilizes the Training Administration 
System to determine the training 
completed by the crew member. 
Additionally the operator may 
discuss with the instructor that 
taught the crew member a specific 
class or set of instruction to farther 
determine the crew members 
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proficiency at a given task. In 
addition, a review of past mission 
accomplishments/assignments and job 
specialties may give insight into 
determining the level of crew member 
training. 

1. 1.2.3. 1 - Develop and give onboard 

training to crew: The ground 

controllers/training personnel may 
need to develop/administer on-orbit 
training to crew members. The prime 
method will be on-orbit on-the-job- 
training (OJT). Another method uses 
a lesson plan that allows the crew 
member to be trained on-orbit by 
studying a ground developed and up 
linked lesson by performing the 
related tasks in a non- 
intrusi ve/destructive manner. 

1.1. 2. 3. 2 - Develop and give training 

to crew on the ground: The crew 

training is grouped into generic 
training and task specific training. 
The generic training is a set of 
training that develops skills and 
knowledge that can be used to 
complete many similar type tasks; 
however, specific training may be 
necessary for training that is not 
included in generic and is required 
for proficiency. The ground training 
will be given to the crew members 
using training manuals, classroom 
instruction, mock-ups, vendor 
facilities, or other NASA Centers. 

1. 1.2.4 - Determine if procedure, 

primary and ancillary SD&D exists: 
This process addresses the steps 
taken by maintenance personnel, both 
on- and off-console, prior to 
scheduling and execution of a 
maintenance activity, to assess 
whether a previously developed and 
approved maintenance procedure, 
possibly from a previous increment, 
is applicable and complete to address 
the maintenance need present in the 
increment in work. 

If the previously developed and 
approved maintenance procedure is 
not adequate, this process outlines 
the appropriate actions required to 
perform additional research, to 
update the procedure to bring it into 
compliance with the demands of the 
annotate the list of source and 
present (in work) increment, and to 


N27- 
Planning 
Constraints 
. & Conditions 



1.1 .2.3.2 
- Develop 
and give 
training 
to crew 
on the 
ground. 


^N30 


Trained Crew availability for 
maintenance task. 
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N5.1 - Proceudre Information 


1 . 1.1 


Toes an approves 
procedure exist 
for this task in 
IODF for current 
increment or 
generic Book?/ 


yesV 

1.1 .2.4.1 

1 

- Retrieve 


a copy of 

© 

Procedure 


for review 




Does 
any procedure 
exist for a 
similar task ? . 


N31 - 
Similar 
Mainten 
-ance 
Proce- 
dure 


no 




an procedure I 
modified to apply > I 
;o current task? / J 

1.1J 


1.1 .2.4.3 -Evaluate 
Sufficiency of SD&D to Support 
Procedure Development and 
Verification 


1 .1 .2.4.4 - Modify Procedure 

—f— 


1.1 .2.4.5- 
Perform 
Procedure 
Verification 


1.1 .2.4.2- 
Add to current 
increment ODF 
(IODF) 


g w&>— 4-1 


1.13 




N32-Task 

Resources 

Identified 


(N9 - Approved Maintenance Procedure ) 


ancillary technical data used to 
create the procedure and clarify its 
contents. 

1. 1.2.4. 1 - Retrieve a copy of 

Procedure for review: This involves 

obtaining a copy of the procedure as 
it appears in the ODF, if it exists. 

1.1. 2. 4. 2 - Add to current increment 

ODF (IODF): The procedure as 

finally written is put into the ODF 
for the upcoming increment. This is 
a formal process controlled by the 
Procedure Documentation, Authoring 
and Control system. 

1.1. 2. 4. 3 - Evaluate Sufficiency of 

Support Data & Documentation 
(SD&D) to Support Procedure 
Development and Verification: The 

SD&D is judged for task sufficiency. 
The purpose is to see if the activity 
has enough supporting information 
that most foreseeable problems or 
questions can be readily handled. If 
the SD&D is not sufficient, then an 
effort is made to obtain the 
"missing" information; either within 
the CCC or from the program office 
resources, i.e., information systems, 
data bases, personal interfaces, data 
that the original equipment 
manufacturer may have, etc. The 
SD&D may be used for support of the 
verification of the procedure even 
though it is not used directly in the 
procedure. 

1.1. 2. 4. 3.1 - Retrieve Additional 

Support Data: If more Support Data 

& Documentation is needed then that 
information must be obtained. See 

1.1. 2. 4. 3 for sources. 

1.1. 2. 4. 3. 2 - Link Additional 

Support Data to Procedure: The 

SD&D must be linked with pointers 
to the activity and its procedure. 
The data may be part of the procedure 
or may be appended to the activity. 

1.1. 2. 4. 4 - Modify Procedure: The 

procedure, if not appropriate for the 
maintenance activity, is changed 
until it is appropriate to the task. 
This includes passing all verification 
requirements. 

1.1. 2. 4. 5 - Perform Procedure 

Verification: When the procedure has 

been written or composed then the 
procedure needs to be evaluated to 
see if it will accomplish what is 
intended. To do this the procedure 
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under goes a verification. Procedure 
verification may be accomplished by 
analysis or by demo nstration. 

' N5.3 - V N23 3 ' 

Ancillary 
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Data& 

Documen- 
tation 
(TD&D) 

Know- 
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Source 
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Source 
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1.1.2.4.3.1 
- Retrieve 
Additional 
Support 
Data 


N22 - SD&D 
Resources Ready to 
support Procedure 
Development and 
Verification 


1.1. 2. 4. 6 - Develop Procedure: If 

there is not an existing procedure 
that can be modified to meet the 
maintenance activity's requirements, 
then a procedure is developed from 
scratch. The Consolidated 

Maintenance, Inventory & Logistics 
Planning (CMILP) system is the tool 
used to pull together the information 
for the procedure. The information 
as completed in CMILP is then 
passed to the Procedure 
Documentation, Authoring and 
Control system for the formal 
procedure development, verification 
and base lining under configuration 
management. 

1.1. 2. 4. 6.1 - Evaluate Sufficiency of 
SD&D to Support Procedure 

Development and Verification: See 

1.1. 2. 4. 3 - Evaluate Sufficiency of 
SD&D to Support Procedure 

Development and Verification 


1 


1.1.1 or 1.1.2.4.1 


1.1 £.4.6.1 - Evaluate 
Sufficiency of SD&D to Support 
Procedure Development and 
Verification per 1 .1 .2.4.3 

1 

1.1.2.4.6.2- Draft 
Preliminary Procedure 



1.1 £.4.6.5- 
Review Procedure 

1 


1.1 £.4.6.6- 
Implement/lncorporate 
suggested modifications 


1 .1 £.4.6.3 - Perform Procedure 
Verification per 1.1 .2.4.5 

*• — 


1 .1 £.4.6.4 - Make . ^ 

changes/updates to procedure pO 


1 .1 £.4.6.5 - Review 
Procedure 


1.1 £.4.6.6- 
implement/lncorporate 
suggested modifications 


1.1 £.4.6.7 -Final 
review of procedure 


1.1 £.4.6.8- Control 
board final approval 



1 . 1 . 2 . 4 . 6. 2 

Procedure: 


Draft 

Develop 


Preliminary 

Procedure; 
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except for verification and base 
lining within the configuration 
system . 

1.1. 2. 4. 6. 3 - Perform Procedure 

Verification: See 1.1. 2. 4. 5 

Perform Procedure Verification 

1.1. 2. 4. 6. 4 - Make changes/updates 

to procedure: The procedure is 

modified based upon verification 
activities to accomplish or better 
accomplish the objectives of the 
procedure. 

1.1. 2. 4. 6. 5 - Review Procedure: The 

review is conducted against the 
Support Data & Documentation, the 
Logistics Support Analysis Records 
used in the production of the draft 
preliminary procedure and the 
standards for procedures. 

1.1. 2. 4. 6. 6 - Implement/Incorporate 

suggested modifications: This is 

modifying the procedure to include 
the recommendations revealed within 
the verification and configuration 
base lining process. 

1.1. 2. 4. 6. 7 - Final review of 

procedure: This is the completion of 

the review and verification process 
just before the procedure goes under 
formal configuration management. 

1.1. 2. 4. 6. 8 - Control board final 

approval: The procedure becomes a 

configuration controlled procedure at 
this point. The process for 

modification and verification may 
need to be repeated if the final 
control board approval is not forth 
coming or minor changes required. 
1.1.3 - Maintenance Activity 

Planning: This is providing to the 

Operations Planner all of the 

information needed to get the 

maintenance activity a position of 
the time line. The preceding process 
should have produced all the needed 
information such that this process is 
straight forward. The internal 

Operations Planner process is not 
covered. 

1.2 - Perform Pre Maintenance 

Activities: This includes all of the 

sub process to prepare for 

maintenance. This is after the 

planning of the maintenance and the 
activities associated with getting to 
the point of actually doing the 
maintenance. 



r 

1.3 


1.2.1 - Orchestrate Console Operators 

to Configure System for 

Maintenance: Prior to execution of a 

repair action, the item/system being 
maintained as well as other systems 
may need to be reconfigured or 
verified in a certain configuration. 

1.2.2 - Monitor/Assist Crew Pre 

Maintenance Repair Activities: The 

console conducting the on-orbit 
maintenance will coordinate the 
procedural details of task execution 
of any pre-maintenance procedure 
being executed by the crew. 

1.2.3 - Configure Console for 

Maintenance Support: OSO prepares 

the console support tools to present 
all information required by him or 
her to support the crew and the rest 
of the Flight Control Team while the 
crew is performing maintenance. 


Nil - 
Systems 
Configured 
for 

Maintenance 


N13 - Crew 
"GO" for 
Maintenance 
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Prior to the start of the maintenance 
activity, the OSO configures the 
Digital Voice Information System 
keyset to contain all voice loops 
required to maintain communications 
with other MCC personnel supporting 
the maintenance activity. 

1.2.3. 2 - Coordinate Video with 

Ground Systems Mission Controller 
(GC): Prior to the start of the 

maintenance activity, OSO will 
ensure that GC will be providing air- 


to-ground video during maintenance 
operations. 

1.2.3. 1 - Retrieve Approved 

Procedure: Prior to the start of the 

maintenance activity, the Electronic 
Documentation Processing (EDP) 
server is used to retrieve a copy of 
the approved maintenance procedure 
for review and use as a checklist. 

1.2. 3. 4 • List Related SD&D and 

TD&D Objects: For each procedure 

used during a maintenance activity, 
the list of reference information 
which was used in the creation of the 
procedure (the DSI-Data Source 
Index) is reviewed, as well as a list 
of any additional data (Ancillary 
TD&D) that will illustrate, describe 
in detail, or otherwise amplify the 
operator's understanding of the 
procedure methodology or the 
hardware involved. 

1.2. 3. 5 - Retrieve SD&D or TD&D 

Object: Once the decision is made as 

to what information is needed for 
quick reference in support of 
maintenance execution, the 

Consolidated Maintenance, Inventory 
and Logistics Planning system is 
used to retrieve the Support Data and 
Documentation and/or Technical Data 
and Documentation for use on 
console. 

1.2. 3. 6 • Retrieve Inventory Data for 

Failed ORU and Spare(s): TBD - The 

mechanics of this has not been 
established yet. 

1.3 - Perform Maintenance Activity: 
The actual execution or conduct of 
the maintenance activity takes place 
within this process. 

1.3.1 - Monitor/Assist Crew 

Maintenance Activities: The console 

conducting the on-orbit maintenance 
monitors/assists the crew during the 
maintenance activity. 

1.3.2 - Collect Maintenance Data: 
This process addresses the activities 
involved with producing historical 
documentation on the conduct of on- 
orbit maintenance. 

1.3.3 - Support Checkout 

Maintenance Item/System: When the 

maintenance item/system physical 
interfaces have been re-established 
and verified, the console conducting 
the on-orbit maintenance requests 
that a system checkout be performed 
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by Ground 

members. 


Controllers/Crew 
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Configured for 
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N15- 
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Maintenance I 
Item/ ▼ 

System 1.4 

, — *— 

N17- On-Orbit 

Maintenance 
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1.4 - Perform Post Maintenance 

Activities: This includes three 

major processes and they are: 

-1.4.1 - Coordinate w/console 

operators to configure system after 
Item Repair 

-1.4.2 - Monitor/Assist Crew Post 

Item Repair Activities 
-1.4.3 - OSO Performs Post Item 

Repair Activities 

1.4.1 - Orchestrate console operators 
to configure system after item repair: 
This is any processes/actions of 
coordinating with the console 
operators and/or crew (through the 
console operators) to get the 
maintenance item/system back in the 
operating configuration. 

1.4.2 - Monitor/Assist Crew Post 

Maintenance Activities: The 

maintenance console operator 
monitors/assists the crew during the 
post item repair activity. 

1.4.3 - Perform Post item repair 

Activities: This is composed of four 



major processes/actions. They are: 

-1.4. 3.1 - Review/Modify Procedure 

against the as Executed Task 

-1.4. 3. 2 - Assure all console and 

Office data is updated 

-1.4. 3. 3 - Assure all data is 

available for external data base 

update 

1.4.3. 1 - Review/Modify Procedure 
against the as Executed Task: 
Annotations are made of deviations 
of the as-executed procedure from the 
official procedure. 

1.4. 3. 2 - Assure all console and 

Office data is updated: This is 

updating any of the console products, 
CMILP resident data or data at the 
office location. 

1.4. 3. 3 - Assure all data is available 
for external MCC data base update: 
This is updating any of the data that 
flows to external MCC organizations. 
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Abstract 


The purpose of this paper is an attempt to get 
the reader to recognize that different 
requirements that are surfacing and to be 
proactive in achieving successful support of 
these systems. This paper will identify areas 
of concern and present some areas of focus 
applicable to the development and support of 
software intensive systems. 


Introduction 


Over the past few years, major weapon 
systems and electronic systems have become 
software intensive. A recognizable pattern 
has occurred whereby system changes in 
hardware are not as dramatic as those 
encountered in the area of software. This is 
very apparent for space systems which are 
positioned, activated and repaired (limited) via 
software programs. The following graph, not 
drawn to scale, depicts a graphical 
representation of the changing from hardware 
intensive to software intensive systems found 
today. 



Due to the rapid changes that occur in 
today's High Technology systems, it is 
imperative that individuals let loose of the 
"Traditional ways" of doing business and 
focus on what is needed to properly develop, 
implement and support these High 

Technology systems which are becoming 
more prevalent in today's space systems. 
Even though the goals of the "traditional" 
processes and methodologies remain relatively 
unchanged, the work effort expended on the 
the Space Station program has resulted in 
recognizing that issues and concerns have 
surfaced that make it imperative to "re- 
assess" the way that development and 
support of software needs to be conducted 
on current and future Space Programs. 

Overview 


In years past, the amount of software written 
constituted a small percent of system 
development. This effort focused upon 
support of the system in terms of repair and 
"checking the health" of the system. If the 
software had errors in it, it didn't make a lot 
of difference in terms of achieving the 
mission. Software was written for diagnostic 
testing purposes. This is not what is being 
experienced in today's high technology arena. 
Computer and its associated software 
technology is undergoing rapid advancement. 
The following drawing shows this lag in time 
and technology between the design of the 
system and the deployment of the system. 


Copyright © 1995 by the American Institute of Aeronautics 
and Astronautics, Inc. All rights reserved. 
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This is not the case anymore, computer and associated software technology is advancing so rapidly 
that: 





Technology which is currently here 


is often obsolete here 


Space systems represent undertakings of 
massive proportions that introduce 
requirements, concerns and constraints 
resulting in new applications of existing 
procedures and methodologies, including 
support. This realization came about on the 
current Space Station program. 

For example, launching the shuttle requires 
volumes upon volumes of data and 
information to assess the safety of the 
propose launch, all of this is accomplished at 
"Real Time" speed. If a major problem 
develops, it is possible to scrub the launch 
with scant seconds to spare. 

With planned manned space systems you 
don't have this type o* luxury, with software 
controlling of having a major part in the 
control of on-board systems, if a "software 
failure" occurs there exists a large potential 
probability of loss of life. It is not possible to 
"cancel". 


Reliability and maintainability are used in 
software development; however, quite a few 
individuals try to view software development 
and associated analyses in the same light as 
hardware. 

When considering software design and 
development and associated analyses for 
assisting in the software Supportability for 
space systems, it is imperative to recognize 
that there is a separation between software 
development and hardware development. 

Due to the nature of the operational scenario, 
not treating software as a separate entity will 
not completely satisfy the determination of all 
Supportability requirements for space 
systems. The following table depicts the 
differences in the difference between 
maintainability and reliability for hardware and 
software. 



flHNM ' | RELIABILITY ... 

MAINTAINABILITY 1 "Mi 

HARDWARE 

probability that a system or product will 
perform its intended function under 
defined conditions at designated times for 
specified operating periods. 

inherent characteristic of a design or 
installation that determines the ease, 
economy, safety, and accuracy with 
which maintenance actions 
can be performed. 

SOFTWARE J 

probability of failure free operation of a 
computer program in a specified 
environment for a specified time 

ease at which software can be 
understood, corrected, adapted, 
and/or enhanced. 
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Definitions 

1 . Correctness - Extent to which a 
program satisfies its specification and fulfills 
the customer's mission objectives. 

2. Efficiency - Amount of computing 
resources and code required by a program to 
perform its function. 

3. Integrity - Extent to which access to 
software or data by unauthorized persons can 
be controlled. 

4. Interoperability - Effort required to 
couple one system to another. 

5. Maintainability - Effort required to 
locate and fix an error in a program. 

6. Portability - Effort required to transfer 
the program from one platform and/or 
software system environment to another. 

7. Reliability - Extent to which a program 
can be expected to perform its intended 
function with required precision. 

8. Reusability - Extent to which a 
program (or part of a program) can be reused 
in other applications. 

9. Testability - Effort required to test a 
program to ensure that it performs its 
intended function. 

10. Usability - Effort required to learn, 
operate, prepare input and interpret output of 
a program. 


As with hardware development, there are a 
number of areas that need to be addressed 
when developing and assessing support 
requirements over the life of a system. The 
following chart delineates some of the 
components of software development and 


support that need to be considered to arrive 
at effective software development and 
support for high technology space systems. 


SPACE SYSTEMS CONCERNS/ISSUES 

SOFTWARE QUALIT Y 

SOFTWARE RELIABILITY 

SOFTWARE SAFETY 

SOFTWARE MAINTENANCE 

MAINTAINABILITY 

HUMAN FACTORS 

ROBOTICS 

REPAIR SCENARIOS 


What follows is a brief description of and 
some guidelines for each of the 
aforementioned areas. 


Software Quality 

Quality is ever present in everything that we 
do. No one individual works in a total 
vacuum, we all have people that rely upon 
what we do. Software quality is applied 
throughout the software development 
process, it is not something we look at after 
writing the code. 

Software quality is comprised of the following 
three (3) components: 

1 . Software requirements - These 
represent the starting block from where 
quality is measured. These make up the 
program definition. 

2. Standards - These tell you how to 
plan and carry out the software development. 

3. Inherent Requirements - These 
represent "Just good, smart" developmental 
practices that support definitive requirements. 
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Software Reliability 

This represents an important component of a 
software program's overall quality, software 
reliability can be measured directly and 
estimated utilizing historical and 
developmental data. Software reliability is 
defined as the Probability of failure free 
operation of a computer program in a 
specified environment for a specified time. 
Failure can be a difficult term to grasp, 
failures can range from something easy to 
correct or something catastrophic. Correction 
of one failure can induce multiple errors (this 
happens when one introduces a "Band-Aid" 
fix to software. 

Hardware-related reliability models are based 
on failures due to wear whereas software 
failures can be traced to design or 
implementation problems. Software reliability 
is usually measured in terms of: 

# of Defects 
K Lines of Code 

Software Safety 


Software safety needs to be looked at intentlv 
when developing a computer program, this is 
especially true when the software is used to 
control safety critical processes. An 


undetected fault in a computer-based control 
or monitoring system could result in 
significant human injury, loss of life, or 
tremendous financial tragedy. When software 
is used as part of the control system, 
complexity can increase by a significant order 
of magnitude. 

Design faults induced by human error - which 
can be uncovered and eliminated in hardware- 
based conventional control - become much 
more difficult to uncover when software is 
used. Software safety is a quality assurance 
activity that focuses on the identification and 
assessment of potential hazards that may 
impact software negatively and can cause an 
entire system to fail. By identifying hazards 
early in the software davelopment process, 
software design features can be specified that 
will either eliminate or control potential 
hazards. 

Hazards are identified and categorized by 
criticality and risk. To be considered 
effective, the software needs to be analyzed 
in the context of the entire system. You do 
not separate the software from the system. It 
should be noted that people are components 
of the entire system. 

I.E., a subtle user input error may be 
magnified by a software fault to produce 
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control data that improperly positions a 
robotic arm. If a set of external 
environmental conditions are met (and only if 
they are met), the improper positioning of the 
robotic arm could cause a disastrous failure. 


Software Maintenance 

There are four (4) activities that are that 
comprise software maintenance: 

1 . Corrective Maintenance - includes the 
diagnosis and correction of one or more 
errors. This activity occurs because it is 
unreasonable to assume that software testing 
will uncover all latent errors in a large 
software system. With systems operating in 
orbit, it is extremely difficult to ascertain all 
the problems that could occur prior to 
becoming operational. Errors that occur in 
orbit will need to be relayed back for proper 
code correction. The possibility exists that 
some errors would not be to be duplicated on 
earth. 

2. Adaptive Maintenance - modifying 
software to properly interface with a changing 
environment. This occurs due to the rapid 
changes that occur within the computing 
environment. New pieces of hardware, new 
operating systems, peripheral equipment and 
other system elements are frequently 
upgraded or modified. When designing a 
major space system, the current method is 
modularity. Here it can be seen that 
hardware and systems will develop over a 
period of time and that changes could occur 
rapidly in the beginning of system 
development resulting in the probability of 
unanticipated requirements and needs. These 
would result in adapting the software to 
coincide with system changes. 

3. Perfective Maintenance - this accounts for 
the majority of all effort expended on 
software maintenance. This activity deals 
with incorporating enhancements to the 
software requested by users. I.E., new 
capabilities or modifications to existing 
functions. 

4. Preventive Maintenance - this activity is 
characterized by reverse engineering and re- 


engineering techniques. This activity occurs 
when software is changed to improve future 
maintainability or reliability, or to provide a 
better basis for future enhancements. 

It should be noted that analogies between 
software and hardware maintenance can be 
misleading. As was pointed out previously, 
software, unlike hardware, does not wear out; 
therefore, any major activity associated with 
hardware maintenance - replacement of worn 
or broken parts -does not apply. 

Adaptive and perfective maintenance tasks 
are the same tasks applied during the 
development phase of the software 
engineering process. To adapt or perfect, you 
need to determine new requirements, 
redesign, generate code, and test existing 
software. This is known as maintenance. 

Problems: 

Most problems associated with software 
maintenance can be traced to deficiencies in 
the way software was planned and 
developed. The following delineates what 
usually causes problems. These need to be 
kept in mind when developing software: 

1 . It is difficult or impossible to trace the 
evolution of the software through many 
versions or releases. Changes therefore need 
to be adequately documented. 

2. It is often difficult or impossible to trace 
the process through which software was 
created. To preclude this document the 
process. 

3. It is often extremely difficult to understand 
"someone else's" program. The difficulty 
increases as the number of elements in a 
software configuration decreases. Maintain 
the software configuration. 

4. "Someone else" is often not around to 
explain. Do not build a "single point failure" 
into the software development. 

5. Documentation doesn't exist or is 
incomplete. It is important to recognize that 
documentation is necessary but it must also 
be understandable and consistent with source 
code to be of any value. 
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Maintenance Side Effects: 


6. Most software is not designed for change. 
Modifications to software are difficult and 
error-prone. 

Maintainability 

Maintainability can be defined quantitatively 
as the ease with which software can be 
understood, corrected, adapted, and/or 
enhanced. Maintainability is affected by 
many factors. These factors include: 
inadvertent carelessness in design, coding, 
testing and poor software configuration. It is 
easy to understand the need for 
standardization of me hodology employed, 
resources and approach. If software is 
viewed as a system element that will 
inevitably undergo change, the chances that 
maintainable software will be produced are 
likely to increase substantially. 

Software Maintainability can be difficult to 
quantify; however, it can be assessed 
indirectly be considering attributes of the 
maintenance activity. The following 
delineates maintainability metrics that relate 
to the effort expended during maintenance: 

1 . Problem recognition time 

2. Administrative time 

3. Maintenance tools collection time 

4. Problem analysis time 

5. Change specification time 

6. Active correction (or modification) time 

7. Local testing time 

8. Global testing time 

9. Maintenance review time 

10. Total recovery time 

At each level of software engineering, 
maintainability should be considered. 
Consideration should be given to: areas of 
future enhancements and potential revisions; 
software portability; system interfaces that 
might impact software maintenance; data 
design, architectural dasign, procedural 
design, and interface design are considered 
for ease of modification and overall design 
quality, review code to stress style and 
internal documentation. 


Design documentation and testing can help 
eliminate error, but there is still the possibility 
of encountering Maintenance side effects. 
When viewing software maintenance, the 
term "side effects" implies an error or other 
undesirable behavior that occurs as a result of 
modification. There are three (3) major 
categories for side effects. 

Coding Side Effects: 

A simple change to a single statement can 
sometimes have disastrous results. Change 
invites error and error always to problems. 
Communication to machines is accomplished 
through programming language source code. 
Although every code modification has the 
potential for introducing errors, the following 
set of changes tend to be more error-prone 
than others: 

1 . A subprogram deleted or changed. 

2. A statement label is deleted or modified. 

3. an identifier is deleted or modified. 

4. changes are made to improve execution 
performance. 

5. File open or close is modified. 

6. Logical operators are modified. 

7. design changes are translated into major 
code changes. 

8. Changes are made to logical tests of 
boundary conditions. 


Data Side effects: 

During maintenance modifications are often 
made to individual elements of a data 
structure or to the structure itself. When data 
change, the software design may no longer fit 
the data and errors can occur. Data side 
effects occur as a result of modifications 
made to the software information structure. 

The following changes in data frequently 
result in side effects: 

1 . redefinition of global and local constants 

2. redefinition of record or file formats 

3. increase or decrease in the size of an array 
or a higher-order data structure 

4. modification to global data 
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5. reinitialization of control flags or pointers 

6. rearrangement of arguments for I/O or 

subprograms 

Data side effects can be limited by thorough 
design documentation that describes data 
structure and provides a cross reference that 
associates data elements, records, files, and 
other structures with software modules. 

Documentation Side Effects: 

Maintenance needs to focus on the entire 
software configuration and not on source 
code modification alone. Documentation side 
effects occur when changes to source code 
are not reflected in the design documentation 
or user-oriented manuals. Whenever a 
change to data flow, design architecture, 
module procedure, or any other related 
characteristic is made, supporting technical 
documentation must ba updated. Side effects 
occur in subsequent maintenance efforts 
when an innocent perusal of technical 
documents leads to an incorrect assessment 
of software characteristics. 

If modifications to the executable software 
are not reflected in the user documentation, 
side effects are guaranteed. Documentation 
side effects can be reduced substantially if 
the entire configuration is reviewed prior to 
re-release of the software. 

Maintenance is the last phase in the software 
engineering process, accounting for the 
majority of all dollars spent on computer 
software. The result is that the amount of 
effort and resources expended on software 
maintenance is growing. Two methods can 
assist in the maintenance process: (1 ). 
Reverse engineering - this extracts design 
information from progiam source code when 
no other documentation exists. (2). Re- 
engineering - takes tha information obtained 
and restructures the program to achieve 
higher quality and, therefore, better 
maintainability in the future. 

Human Factors 

When developing systems it is extremely 
important to note Individual skill level 
differences, personality variations, and 


behavioral distinctions among users of a 
computer-based system. 

An interface acceptable for one skill level 
might be inadequate for another. The same 
interface for two individual of the same skill 
level but different personalities might be user 
friendly for one but unfriendly to the other. 

An interactive computer-based system rarely 
enables a user to do something entirely new. 

In most cases, the system is built to automate 
(and thereby improve) certain tasks that were 
previously performed by hand or some other 
approach. This is very useful in hazardous 
environments. I.E., external repair of a space 
system can be accomplished by a technician 
without venturing outside the craft using 
computer controlled robotics Ideally, the new 
technology enables a user to perform tasks 
better, faster, more efficiently, more 
accurately, more safely, or less expensively. 

Even with interactive computer-based 
systems, the following tasks are almost 
always performed: 

Communication tasks - activities that 
enable information to be transferred from one 
individual to another. 

Dialog tasks - activities that enable the 
user to direct and control interaction with the 
computer-based system. 

Cognitive tasks - activities that are 
performed once information has been 
obtained; activities associated with the 
function of the system. 

Control tasks - activities that allow the 
user to control information and cognition and 
order process through which other generic 
tasks occur. 

Interfaces can range from simple menus to 
icons, windows, touch screens, and pointing 
devices. 

Simple menus provide the user with an overall 
context and is less error prone that typing 
command lines. If comprised of numerous 
layers, simple menus can be tedious to use 
since the user needs to transverse through 
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the different layers to achieve the goal. It is 
easy to see that this approach is not efficient 
for running space systems where time is a 
critical factor. 

With sophisticated hardware being developed, 
it is imperative that better interfaces be 
utilized. To support today's high technology 
systems, the following improvements in 
interfaces have evolved: 

1 . Different types of information can be 
displayed simultaneously, enabling the user to 
switch context without losing visual 
connection with other work. Windows 
enables the user to perform many 
communication and cognitive tasks efficiently. 

2. Many different interactive tasks are 
available through pull-down menu schemes. 
These menus allow users to perform control 
and dialog tasks in a facile manner. 

3. Use of graphical icons, pull-down menus, 
buttons, and scrolling techniques reduce the 
amount of typing. This can increase the 
interaction efficiency. 

Multitasking, window-oriented, point and pick 
interfaces make the human computer interface 
more friendly, faster and easier only if careful 
design of the interface is conducted. 

Design Issues 

During the design of a user interface, four 
common design issues almost always surface: 
System response time, user help facilities, 
error information handling, and command 
labeling. 

1 . System response time - this is measured 
from the point at which the user performs 
some control action until the software 
responds with the desired output or action. 
Response time possesses two very important 
variables: length and variability. 

Length - this represents the length of 
time associated with a response. Too short a 
response time can cause the user to rush and 
possibly make mistakes. Too long a response 
is not efficient. 


Variability - this refers to the deviation 
from average response time. Varying the 
response time with wide margins can cause 
stress on the part of the user. There is 
enough stress being in orbit without adding 
more. A consistent response time is 
beneficial for the user. 

2. Help Facility - Interactive systems require 
some sort of on-line help that enable the user 
to get a question answered or resolve a 
problem without leaving the interface. 

The following represent design issues when 
considering a help facility: 

a. Will help be available for all system 
functions and at all times during system 
interaction? 

b. How will the user request help? 
(Help menu, special function key, HELP 
command). 

c. How will the help be represented? 
(Separate window, reference to a printed 
document, one or two line suggestion 
produced in a fixed screen). 

d. How will the user return to normal 
interaction? (Return button displayed on the 
screen, function key, or control sequence) 

e. How will the help information be 
structured? (Flat structure where all 
information is accessed through a keyword, 
layered hierarchy of information - provides 
increasing detail as the user proceeds into the 
structure, hypertext). 

3. Error Messages - these are delivered to the 
user of interactive systems that something 
has gone awry. If poorly designed/displayed, 
error messages impart useless or misleading 
information and serve only to increase user 
frustration. Most users have seen error 
messages that present a failure type and a 
code (i.e.. System Failure -- 23S]. This 
indicates a failure has occurred but not what 
it is or even where to look. Every error 
message or warning should have the 
following characteristics: 
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The message should describe the 
problem in jargon that the user can 
understand. 

The message should provide 
constructive advice foi recovering from the 
error. 

The message should indicate any 
negative consequences of the error so that 
the user can check to ensure that they have 
not occurred (or correct them if they have). 

The message should be accompanied 
by an audible or visual cue. This can be a 
beep or a momentary flash of a identified 
“error color". 

The message should be 
nonjudgmental. Do not place blame on the 
user. 

Interface Design Guidelines: 

There are three categories of human computer 
interface design guidelines - general 
interaction, information display, and data 
input. 

General Interaction - this area crosses into 
information display, data entry, and overall 
system control. The following should be 
considered: 

Be consistent - use a consistent 
format for menu selection, command input, 
data display, and other functions that occur. 

Offer meaningful feedback - provide 
the user with visual and auditory feedback to 
ensure that two-way communication 
(between user and interface) is established. 

Ask for verification for any non-trivial 
destructive action - if the user requests the 
deletion of a file, indicates that substantial 
information is to be overwritten, or asks for 
termination of a program, an "Are you sure 
...?" message needs to appear. 

Permit easy reversal of most actions. 

Reduce the amount of information 
that must be memorized in between actions - 
the user should not be expected to remember 


a list of items so that they can be reused in a 
subsequent function. Memory load should be 
minimized. 

Seek efficiency in dialogue, motion, 
and thought - Keystrokes should be 
minimized, distance a mouse travels between 
picks needs to be considered, the user should 
never be placed in a situation where they 
need to ask "What does this mean?". 

Forgive mistakes - the system should 
protect itself from user errors that might 
cause it to fail. 

Categorize activities by function and 
organize screen geography accordingly - One 
key benefit of a pull-c.own menu is the ability 
to organize commands by type. 

Provide help facilities that are context- 
sensitive. 

Use simple action verbs or short verb 
phrases to name commands - a lengthy 
command name is mo'e difficult to recognize 
and recall. It can take up space on a menu 
list. 

Information Display: 

Information is displayed in many different 
ways - with text, pictures, and sound; by 
placement, motion, and size, using color, 
resolution; and even by omission. Information 
needs to satisfy the needs of the user; 
therefore, it can not bt incomplete, 
ambiguous, or unintelligible. The following 
guidelines focus on information display: 

Display only that information that is 
relevant to the current context - the user 
should not have to wade through extraneous 
data, menus, and graphics to obtain 
information relevant to a specific system 
function. 

Don't bury the user with data - use a 
presentation format that enables rapid 
assimilation of information. Graphs or charts 
should replace voluminous tables. 

Use consistent labels, standard 
abbreviations, and predictable colors - the 
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meaning of a display should be obvious 
without reference to some outside source of 
information. 

Allow the user to maintain visual 
context - If graphs are. scaled up and down, 
the original image needs to be displayed 
constantly so that the user understands the 
relative location of the portion of the image 
currently being viewed. 

Produce meaningful error messages. 

Use windows to compartmentalize 
different types of information. 

Consider the available geography of 
the display screen and use it efficiently. 


Data Input: 

Much of the user's time is spent on providing 
system input. This can be accomplished by 
means of a keyboard, mouse, digitizing tablet, 
and even voice recognition. The following 
guidelines focus on data input: 

Minimize the number of input actions 
required by the user - reduce the amount of 
typing required by the user. This can be 
accomplished by using a mouse to select from 
predefined sets of input; using a "Sliding 
scale" to specify input data across a range of 
values; using "macros" that enable a single 
keystroke to be transformed into a more 
complex collection of input data. 


Maintain consistency between 
information display and data input - the visual 
characteristics of the display (e.g. text, color, 
size, placement) should be carried over to the 
input domain. 

Allow the user to customize input - an 
expert user might decide to create custom 
commands or dispense with some types of 
warning message and action verification. 

Interaction should be flexible but also 
tuned to the user's preferred mode of input. 

Deactivate commands that are 
inappropriate in the context of current actions 
- this protects the user from attempting some 
action that could result in an error. 

Let the user control the interactive 
flow - the user should be able to jump 
unnecessary actions, change the order of 
required actions (where possible) and recover 
from error conditions without existing from 
the program. 

Provide help to assist with all input 

actions. 


Repair Scenarios 

When analyzing spact systems some of their 
peculiarities surface, one are is that of their 
evolving "repair scenarios". The following 
chart depicts the growth trend with regard to 
who or what accomplishes the repair: 


SPACE SYSTEM REPAIR SCENARIOS 
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Repairs currently being performed by human 
technicians will be transferred to robotics and 
eventually we will see a large degree of 
software "self-repair” being accomplished 
(which is facilitated by reusable software and 
modularity). This allows on-board personnel 
to focus their efforts on the primary mission 
of the space system. 

Robotic Tasks 

Due to the ever present life threatening 
environment outside the station, robotic tasks 
are to be used where practical and cost 
effective. Markings and lights need to be 
provided to support computer vision and other 
vision requirements. The plan is for evolving 
space station design incorporating increased 
utilization of autonomous Robotic devices. 

The ultimate goal is for all EVA tasks to be 
performed by Robots, until that time, humans 
need to journey outside the space craft into 
probably the most dangerous and unfriendly 
environment known to man and assist Robots 
in performing necessary tasks.. This means 
that space systems will evolve into software 
intensive systems. 

Bottom Line 

It seems apparent that software developers 
need to make more use of "reusable" code. 
This represents code that is written once and 
possesses multiple uses. As more space 
systems are developed, code written and 
debugged for one system can be "re-used" on 
other systems. This demonstrates the need 
for standardization and modularity of 
software. Standardization of parts (hardware 
application) has been in effect for a number of 
years. 

Also, there needs to be more work done in 
the area of artificial intelligence in terms of 
software being able to maintain and correct 
itself. This can be seen if one understands 
that space system software is embedded in 
the control/monitoring subsystems for orbit- 
sustaining critical mechanical and electronic 
systems. 

The growth trend for the repair scenario on 
space systems is more toward robots and 


self-repairing software. The space station's 
purpose if for materials research and life 
sciences research. It is not the intent of on- 
board personnel to deviate from this and 
spend long hours on effecting repairs. 
Therefore, design and Supportability 
requirements identification via LSA need to 
keep pace with the rapidly changing advances 
in technology. 

Space systems exist in a very hostile 
environment where information flow is very 
important and time critical. These software 
systems are real-time systems that must 
integrate hardware, software, humans and 
database elements. Real-time systems 
generate some action in response to external 
events. To accomplish this, they perform 
high speed data acquisition and control under 
severe time and reliability constraints. 

Although all software must be reliable, real- 
time systems (especially those in space 
systems) make special demands on reliability, 
restart capability and fault-recovery. Real- 
time systems process a continuous stream of 
incoming data. During the designing of the 
system, it is imperative that data will not be 
missed. 

Real-time systems must take into account the 
usual software engineering factors (i.e. 
reliability, maintainability, human factors, etc.) 
but also they need to contain restart 
capability, fault recovery mechanisms and 
have built-in redundancy to ensure back-up. 

This realization is just starting to surface on 
the Space Station program and will continue 
to do so on other space programs. 
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Abstract 

This document reviews some current 
applications of Electronic Verification and the benefits 
such applications are providing the Kennedy Space 
Center (KSC). It also previews some new 
technologies, including statistics regarding 
performance and possible utilization of the technology. 

Introduction 

As we enter into the 21st century we are 
finding more and more challenges and projects with 
even higher goals and standards. We are also finding 
lower budgets and a need for new levels of efficiency 
and innovation. Fortunately, the coming century 
brings with it a wealth of new ideas, perspectives, and 
technology. Electronic Verification and the Automatic 
Identification Industry are just part of this new era. 
With a little planning and education we will find 
ourselves ready to take full advantage of what the 
future has to offer. 

Barcode applications at KSC 

The benefits of an Electronic Verification 
(EV) system can be discussed, savings can be 
calculated, and all the estimates, charts, proposals, and 
comparisons can be done, but if the ideas are not put 
into practice it doesn’t mean anything. The Kennedy 
Space Center has taken steps toward using some of this 
available technology. Barcodes have found their way 
into many different areas, from hardware and software 
to boxes, blankets, and badges. Any area that requires 
accurate tracking and accountability are looking at 
putting EV systems in place if possible. The world of 
Mission Kits is particularly interested in implementing 
an EV system for hardware tracking. Mission Kits are 
sets of hardware that are required for" shuttle missions. 
Some are mission specific while others are considered 
standard equipment. There are approximately 110 
different Mission Kits used throughout the space 
program for various applications. The largest of these 
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kits, the V073 kits, contains over 10,000 individual 
parts. Currently, efforts are being made to finish a 
large barcoding project for the V073, V7XX, and 
V8XX kits. Once completed, the barcode tracking 
system will provide greater visibility and status of 
Mission Kits within the processing flow. Supporting 
hardware and software are in place and the actual 
application of barcode labels is in its final stages with 
other applications scheduled. 

Another benefit that is derived from the use of 
the barcoding system can be seen during assembly of 
the Mission Kits in the world of payload integration. 
Before EV was introduced to the warehouse, the 
procedure was filled with bottlenecks and opportunities 
for error. First, a list of required parts would be 
received at the warehouse, marked for kitting. A 
physical retrieval of all the parts listed was required as 
well as documentation of the hardware for 
accountability purposes. Once a part was removed 
from the shelf it had to be removed from the database 
as being available. Therefore, after retrieval of the 
hardware, the computer was updated via keyboard 
entry. Mistakes were made during kitting because of 
copy errors, illegible handwriting, misplaced parts, or 
in the entry of information into the computer. A study 
performed by RI estimated that over 10,000 errors per 
month could have been attributed to keystroke errors 
alone, during data entry in the Orbiter Processing 
Facilities (OPF). And since one list required several 
people across multiple shifts to complete, the 
possibility for errors was increased. With a barcode 
system a portable scanning unit can now be taken into 
the warehouse to scan in the barcode of the part 
retrieved. This eliminates the possibility of a copy 
error or the recording of an inappropriate number 
(OCN number for example). After the collection is 
complete the information on the portable scanner can 
then be downloaded into the computer, again removing 
the possibility for human error. Plus, the system can 
compare the downloaded information to the kit 
requirements and display any discrepancies. This 
serves as another safeguard to help eliminate errors, 
reduce paper processing, and increase the accuracy of 
inventory data. And with increased accuracy comes 
monetary benefits. One survey estimated that 
implementing barcodes into the world of payload 
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integration would generate over $91,000 per year in 
recurring savings. 

Unconventional barcoding 

EV systems are not limited to ‘hardware’ 
tracking applications. Using a barcode system on 
paperwork can also increase productivity and reduce 
errors. An Automatic Identification system is being 
used in the Test Assembly and Inspection Record 
stations (TAIR) in the Obiter Processing Facilities. 
The TAIR stations keep track of work that is being 
done according to Work Authorization Documents or 
WADs. WADs can be prepared for tile work, orbiter 
work, or even ground support equipment work. Each 
time a tasks is completed, the WAD must be logged in 
as finished and then prepared for the QDC or Quality 
Data Center to be archived. Depending on the position 
of the orbiter in the flow, the TAIR station can receive 
as many as thirty or forty documents a day to close out. 
Previously, this has been done by manually reading 
through the stack of documents, recording the WAD 
number, and alphabetizing the list according to system. 
At the end of the day this was a two hour job that 
nobody wanted. By assigning each WAD a barcode 
that would pull up all the information associated with 
that document and printing a cover page, much of this 
hassle was avoided. To scan in forty documents with a 
barcode wand takes about five minutes, and the 
computer automatically sorts the numbers and prints 
out a listing. When QDC picks up the documents they 
can simply scan the barcodes to verify the list with a 
portable scanner and then download that information 
into their computer record system back at the office. 
This saves time, eliminates errors, and decreases the 
number of times the information has to be manually 
entered into the computer. 

Barcodes are also being used in the TAIR 
stations to replace the manual entry of repetitive 
information. When creating the WAD cover sheet, 
information must be entered to identify the type of 
work, location, and date, as well as other information. 
Barcodes are being used instead of the keyboard to 
shorten processing time and again reduce human 
errors. For instance, many of the WADs that go 
through a TAIR station will have an identification code 
that tells which OPF Bay the work is being done in and 
which orbiter and flight number is receiving the work. 
So a sheet of barcodes has been created that allows the 
user to simply scan a barcode in place of typing the 
information. The information contained in the 
barcode is translated directly into ASCII, (just as it is 


from the keyboard), fills in appropriate fields, and 
advances the cursor to the next line requiring input. 

Another possible use for barcodes in the TAIR 
station is the charge out record. Efforts are being made 
to replace the handwritten sign out sheet with an EV 
system that will electronically assign responsibility to 
the technician picking up the WAD. Not only will this 
provide a more legible record it will also track the time 
spent in each phase of the repair. This should aid in 
streamlining work procedures and reducing 
bottlenecks. 

Investigating new technology 

The current technology used at KSC has many 
applications that are being taken advantage of, and 
there are other possibilities that make the barcode 
system a tool that will provide benefits well into the 
future. There are, however, some limitations to the 
barcode symbology. And while many of these 
limitations can be reduced or eliminated through the 
computer programming and software, there is still 
room for improvement. That is where the next 
generation of EV will take over. This new technology 
is two dimensional Compressed Symbology or CS. CS 
simply expands on the idea of the barcode. It still uses 
a machine readable code and corresponding software to 
process the received data, but it takes advantage of new 
ideas and advancements in technology. 

Vericodes are currently the most prominent 
form of two dimensional symbols available. Two 
dimensional coding systems were first introduced in 
the form of tiered or layered barcodes by INTERMEC 
back in 1987, called Code 49. Other, similar coding 
systems soon followed. These included Code-a-Block, 
PDF 417, and 16K. While these forerunners of two 
dimensional technology were important to the 
development of the basic foundation, Vericodes are 
currently at the peak of this evolution. 

Vericodes were created by Veritec, a 
California based company that was started when 
Robert Anselmo patented his ideas for the system in 
May of 1990. A Vericode is described as a symbol that 
includes a square array of data cells surrounded by a 
border of orientation and timing cells. Information 
related to the encoded data is contained within the 
square, while timing and orientation information about 
the actual symbol, is found along on the edges of the 
square. 
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Sample Vericode (Average size) 

Vericodes use Charge Coupled Devices (CCD) to scan 
and decode the symbols. The CCD's look more like a 
high resolution camera, but the principle behind the 
technology is similar to that used on barcodes, 
specifically reflection scanning. 

It is the versatility of the Vericode that brings 
it to the cutting edge of innovation. It's capacity is 
greater, it's durability is better, its accuracy is 
improved and the Vericode is an actual compressed 
symbology. It uses mathematical algorithms to convert 
streams of data into coded patterns. Therefore, there is 
not the one-to-one mapping of character to symbol that 
is found with conventional barcodes. This allows for a 
greater amount of information to be stored in the same 
amount of space. In fact, the capacity of the Vericode 
is nearing one hundred times that of a barcode. The 
average Vericode is 3/8 inch square and contains 
anywhere from 20 to 50 characters. In comparison the 
average barcode is approximately 3/8X1 inch and 
contains 5 to 9 characters. Microvericodes have also 
been developed that are as small as four microns 
(4/10,000 of a meter), which can be decoded using a 
microscope. Using ultra high density data 
compression these symbols can still contain up to 16 
characters. 

Another advantage of Vericodes is their 
durability. This is not only a reflection of the various 
marking methods developed for the symbol, but also an 
indication of the error checking and redundancy built 
into the system. Vericodes can be damaged or missing 
up to 50% of the symbol, and through the use of the 
algorithms and built in redundancy, still recover the 
encoded data. 

Speed and accuracy are not lost due to this 
improvement in size and capacity. The accuracy of the 
system can be set to the limits desired by the user. 
Currently the error rate is set arbitrarily at one per 
seven million. During lab tests, a Vericode system 
successfully decoded four million symbols without 


error. This test was repeated with similar results. This 
would correspond to approximately 635 million bits of 
data. The speed of this process can be set to decode up 
to 60 symbols per second. 

Another advantage of the Vericode is that it 
can be decoded regardless of it's orientation. The outer 
edge of the square contains information that provide 
the capability for 360 degree readability. This 
information could also be used to determine the 
orientation of the part the Vericode labels. Such a 
property could have applications in the manufacturing 
and assembly industry where alignment and orientation 
are critical. 

With the variety of advantages that are 
available through the use of compressed symbology, 
the limits are only that of finding beneficial 
applications and utilization of this technology. 

And while there are many benefits to the 
Vericode system, there are also drawbacks which must 
be examined before barcodes are completely 
abandoned. One of which is that there are real-time 
considerations when dealing with a new system. The 
idea to implement the barcode system began back in 
1982 and has yet to achieve completion. The ability to 
change things overnight does not occur just because of 
a breakthrough in technology. The incorporation of 
the Vericode will take time even if it is deemed 
necessary and extremely beneficial. Another 
consideration is that of compatibility. Currently, the 
barcode systems do not have the capability to read 
Vericodes, and it would be hard to phase in a Vericode 
system. Money is of course another factor not to be 
overlooked. Cutting edge technology is never 
inexpensive, especially when the project is as far 
reaching as that of the space industry. The availability 
of the product is limited solely to Veritec and that 
would be a single point of failure in the system. 

Conclusion 

Electronic Verification does have potential 
and the space industry needs to take full advantage of 
the opportunities available with it, but we must also be 
reasonable in our approach. Electronic Verification as 
a whole has provided us with many benefits and 
savings as well as the ability to see new possibilities. 
We need to continue to work toward finishing the 
project started 14 years ago, but not dismiss upcoming 
ideas because of complications. We need to continue 
to consider new applications for the current resources 
and think of ways to incorporate new technology into 
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both prevailing and upcoming systems. As long as we 
continue to think, apply, and strive for efficiency, we 
will continue to grow, improve, and succeed. 
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Abstract 

Goddard Space Flight Center (GSFC) on site and leased warehouses contain thousands of items of Ground Support 
Equipment (GSE) and flight hardware including spacecraft, scaffolding, computer racks, stands, holding fixtures, test 
equipment, spares, etc. The control of these warehouses, and the management, accountability, and control of the 
items within them, is accomplished by the Logistics Management Division, Code 230. To facilitate this management 
and tracking effort, the Logistics and T ransportation Management Branch, Code 234, is developing a system to provide 
warehouse personnel, property owners, and managers with storage and inventory information. This paper will 
describe that PC-based system and address how it will improve GSFC warehouse and storage management. 


Introduction 

At any given time there may be a dozen or so space 
projects in various stages of development at NASA’s 
Goddard Space Flight Center (GSFC) in Greenbelt, 
Maryland. COBE, EUVE, BBXRT, HST, GEOTAIL, 
GGS, GOES, SPARTAN, SHOOT, EOS, GRO, TRMM, 
XTE, are just a sampling of the acronyms and 
abbreviations that make up the alphabet soup of project 
names at GSFC. Each of these projects has varying 
amounts of space flight hardware, flight support 
equipment, and ground support equipment that is used 
for fabrication, manufacture, assembly, test & 
integration, launch support, or operations. When this 
equipment is not in use, it must be stored. The HST 
project alone requires approximately 22,000 square 
feet of storage space for GSE and hardware. After the 
launch of a project, equipment is placed into storage for 
a myriad of reasons. These include reuse on the same 
project, reutilization by another project, or use for a 
servicing or repair effort. The equipment may also be 
declared excess to be screened for utilization by other 
agencies. In order to effectively manage a storage 
program, records must be maintained that can, as a 
minimum, identify the item and its location in the 
warehouse. Additional information such as the owner, 
the owner’s phone number, physical dimensions of the 
equipment, when it was placed into storage, expected 
duration of storage term, special environmental and/or 


handling requirements, etc., is also needed by the 
warehouse manager. As the quantity and complexity 
of information increases, it becomes readily apparent 
that an automated system for managing and 
manipulating the data and preparing reports becomes 
an asset, if not a necessity. To more effectively 
manage the warehouses and the assets they contain, 
logisticiansofthe Logistics Management Division/Code 
234, sought data base management system that could 
be adapted to their needs. When an existing system 
could not be readily identified, they set out to develop 
their own. As a result, SIMS has been developed and 
is now undergoing system test and refinement at 
GSFC. 

General Requirements 

Code 234 desired that the system be inexpensive to 
develop due to the budget constraints that affect most 
government agencies. They also wanted a PC-based 
system to preclude the need for exotic or expensive 
special-purpose hardware or software. The GSFC 
Local Area Network (LAN) was to be used to provide 
multiple workstation access to the system for 
simultaneous use from both contiguous and remote 
locations. Although the system was to be developed 
and used primarily by Code 234, it would have the 
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potential to be used by the flight projects and other 
organizations for inventory control of their hardware. 
To ease the burden of the user, the ability to expand the 
system to use a full-feature bar code capability was 
required. Also, the software had to be fully expandable 
to meet future requirements such as being able to 
interface with optical disk storage and imaging. Imaging 
was desired to enable users to have a ready display of 
the items in storage especially for identifying potential 
forutilizationbymorethanoneproject. It was envisioned 
that this data base system was to be the first of a series 
of applications to ease the burden of inventory control 
at GSFC for both capital and non-capital equipment. 

Inventory Control 

SIMS was developed to be a menu-driven inventory 
control package that could provide rapid information on 
the status of inventories, the location of items, and a 
history of 2transactions. Controls within the software 
allow the users to perform inventory tracking and 
control by project, transfers, and inventory maintenance. 
Code 234 dictated the following functions as necessary 
to SIMS: 

Project Equipment Receipt 
Transfer 

Inventory /Location Maintenance 

Equipment History 

Tables 

Reports and Forms 

Batch Updates with Verification 

Forms Generation 

File Import/Export Capability 

Bar Code Scanning 

Graphic Imaging 

Interface with other property control 
systems (NEMS, NPDMS) 

Equipment Receipt 

The Equipment Receipt function is derived from a 
listing or importable database of equipment to be 
entered into the inventory. This listing is provided by 
projects or organizations which own the equipment. 
The listing is used to process and verify receipts and to 
forecast space requirements for utilization and planning. 
SIMS has the capability to check recordsfor duplication 
during manual entry or import of data from a list. Once 
the item has been entered into the system, the system 
automatically flags available storage locations that fit 
the parameters and criteria entered into the record. 
When the record is completed and saved, the item 
quantities are entered as received and automatically 


added to the update buffer for appending to the main 
inventory file. 

Transfers 

The T ransfer File contains records with information on 
the movement of equipment forthefollowing conditions: 

From one GSFC location to another 
From one bin to another 

From container to clean room and/or back into 
storage 

If an item is removed from the inventory because it has 
been excessed, incorporated into a product, returned 
to the supplier/producer, oris withdrawn from inventory 
for any other reason. 

The T ransfer File provides most of the data for a History 
File and it includes all fields necessary to indicate a new 
location, transfer date, transfer document, new 
responsible party, etc., and must automatically append 
to the History File whenever a transfer is entered. 
When equipment ownershipchanges, SIMS will globally 
replace organization code or other unique fields related 
to ownership. SIMS will also globally replace locations 
for any set of items. 

Inventory/Location Maintenance 

The Inventory Maintenance File provides access to 
defined trackingtools and includes thefollowing specific 
capabilities: 

Project Inventory by Project - The historical file of 
active/closed projects accessed through a pop up 
screen or by manually entering the project number. 

Current Inventory Status - Provides the current 
inventory by project and/or location, with automatic 
flags if schedule review action is required. 

Space Utilization and Projections - Provides graphic 
and tabular records of storage space utilization, 
and provides forecasts of space needs derived 
from project requirements defined in the Project 
Equipment Receipt records. 

Periodic, regular Transaction Reports by Project 
and/or Location - Provides the basis for periodic 
activity reporting. 

SIMS includes an Interactive Locator System to assist 
in the warehousing and management of inventory by 
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selecting and displaying tabular listings of available 
storage locations. The storage location dimensions for 
each storage facility and grid locations within the storage 
facility are entered into the system. Information such 
as physical description (e.g., 2nd tier or drawer #6) and 
load limits of bin/storage areas arealso entered into the 
system. Available bins/storage areas are selected 
against information entered into the database for 
individual inventory items. In usage, for example, the 
weight and dimensions of an inventory item would be 
entered along with relevant environmental requirements 
such as temperature, humidity, etc., The system would 
search all available storage locations and bins, and list 
those locations that match the required parameters. In 
addition, using data entered into the database for 
inventory items, the system will generate space 
utilization and forecasting reports for use in managing 
existing warehouse space and planning for future 
storage needs. NASA-defined tracking requirements 
are built into the system design. Any field or combination 
of fields in the database can be queried for information 
on the inventory and its movement. This includes 
capabilityfortracking/verification.downtoand including 
the level of detail necessary for the verification that 
equipment has been loaded onto a vehicle for delivery, 
and (as a next step) then delivered. The system is 
capable of matches and near matches, sorting in order 
by closest match, and indicating where exact matches 
do not occur. 

Equipment History 

The software maintains a historical record of all record 
changes for each item of equipment. This history is 
displayable on request either as a movable window 
over the record display or as a full-screen display which 
may be scrolled as necessary. An item report can also 
be formatted providing the main record information of 
a particular item and its chronological history. The 
history files are a permanent part of the record and are 
updated automatically whenever the data base is 
updated and the update buffer is cleared. Data can be 
entered directly into the history database and edited 
without accessing the property record. History data 
can be entered in random order and will always be 
displayed in chronological order. 

Tables 

Tables are available for access through pop-ups and 
windows to provide rapid lockup capability for the 
following database fields: 

Location Table - Relates location bar codes to 

clean rooms/containers/warehouses/bins. 


Project Table - Provides information on GSFC 
projects including data such as project name, 
location, responsible person, phone number, 
inventory locations, and assigned project assembly 
location. 

ManufacturerTable-ContainsManufacturerCodes 
(CAGE) as referenced in Defense Logistics Agency 
Cataloging Handbook. 

Unit of Measure Table - Contains unit of measure 
information expressed as a two-character 
alphabetic code that denotes a recognizable 
physical measurement (length, weight, volume) or 
count of an item ( foot, gallon, pound, each). 

Environmental Code Table - Contains specific 
conditions (i.e., temperature, humidity, purge, 
cleanliness, packaging, inspection) under which 
an item is handled, stored, or maintained. 

Hazard Class Table - Contains hazard related 
categories based on NASA requirements. 

Storage Location - Contains information related to 
NASA utilized storage sites. 

Status - Contains NASA developed and approved 
status codes and descriptors. 

Condition - Contains condition codes and 
descriptors. 

Transfer Types - Contains codes and descriptors 
for type of transfer categories (i.e., Shipped to 
another location, moved to another bin, final 
disposition, declared excess, etc.) 

Document Type - Contains information on 
authorizing document types. 

Address Table - Shipping address. 

Security Table - List of authorized signature/ 
approval codes. This table is accessible to users 
and is maintained by the GSFC Designated System 
Supervisor. 

SIMS software accommodates at least 20 additional 
user-defined tables without software modification. SIMS 
provides for rapid marking of data ranges within tables 
allowing direct entry into the database utilizing the 
mouse. 
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Reports and Forms 

SIMS has a very flexible report generation capability, 
reporting to screen, disk, or to choices of at least ten 
common laser and matrix printers. Reports include 
inventory status, stock location, monthly operations 
reports, etc., and has a menu-driven capability to 
produce ad hoc reports forany of the records. Searches 
can be accomplished using variables such as project 
code, receipt or issue dates, location, etc., and report 
to screen, disk, or printer. The system can also 
generate forms. The forms which have been scanned 
are available on screen for the operator to fill out and 
print. Logistics forms such as shipping documents, 
storage requests, etc. can be produced automatically, 
retrieving applicable fields from the database records. 
The security levels within SIMS allow users to 
electronically approve their requests, thus eliminating 
the need to send the form to the Storage Manager and 
cause undue delays in processing requests. SIMS can 


also produce property labels including bar codes for 
property identification and control. 

Summary 

Initial SIMS development is completed, and the system 
is presently undergoing test, evaluation and debugging 
by Code 230 Logistics Management Division personnel 
at GSFC. A data entry clerk has transferred existing 
storage data into the system and has completed the 
on-screen forms fornew storage requests. SIMS users 
will have Local Area Network (LAN) access to SIMS, 
and the requirement for hard copy paperwork will be 
eliminated. It is anticipated that SIMS will greatly 
facilitate the storage operations and inventory control 
of project hardware and equipment at GSFC. The 
inherent flexibility of the system will enable the 
government to expand its capabilities as the need 
demands. 
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Our Desert Storm experience in the tactical utility of 
DoD space vehicles demonstrated that DoD’s 
investment in space technology can provide a 
significant military advantage during times of crisis 
and war. The satellites what gave us such marvelous 
intelligence in locating, tracking, and enabling the 
successful attack of key targets resulted in a 
spectacular military success. However, without an on- 
orbit servicing capability, the fuel consumed to 
maneuver these satellites into position over the 
battlefield shortened their useful life by as much as 
two years. During the 1970’s and 1980’s, the Air 
Force aggressively pursued an or-orbit support 
capability to support and maintain it’s space-based 
assets. However, in the early 1990’s, budgetary and 
political priorities canceled the programs that would 
have made this a reality. Realizing that a future 
decision may be made to reinvestigate on-orbit 
support, the United States Space Command 
(USSPACECOM) sponsored a study to document 
efforts undertaken by the Air Force during the 1970’s 
and 1980’s in developing strategies and actions to 
achieve certain tenets of on-orbit support. The study 
represents an attempt to gather, review, summarize, 
and archive the most important research performed 
during this period. It will serve as a historical 
perspective upon which to base future research and 
development activities. This paper presents an 

overview of that study. 1 

INTRODUCTION 

From the 1960’s through the 1980’s, on-orbit support 
concepts and analytical tools were developed by 
National Aeronautics and Space Administration 
(NASA) and DoD to access and evaluate the potential 
for on-orbit servicing of space systems. Many studies 
were performed to assess the technical feasibility and 
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cost effectiveness of accomplishing satellite 
maintenance and servicing operations in space. 

In general, these studies concluded that on-orbit 
maintenance and servicing is technically feasible and 
that no technology breakthroughs are required. 
Depending on constellation size, location, and on- 
orbit support concept utilized in the analysis, these 
studies demonstrated a potential life cycle cost 
savings range of 10 to 50 percent through the 
employment of an or-obit support strategy. 

With the cancellation of the Orbital Maneuvering 
Vehicle (OMV) and the Satellite Servicer System 
Flight Demonstration (SSS/FD) programs, the Air 
Force has not played an advocacy role or 
demonstrated an interest in developing an on-orbit 
support capability. NASA, on the other hand, has 
continued to develop an on-orbit support capability 
that was, again demonstrated during the Hubble Space 
Telescope (HST) repair mission. 

BACKGROUND 

The March 1992 update of Air Force Manual (AFM) 
1-1, Basic Aerospace Doctrine , addresses the 
increasing role of space assets in sunporting and 
sustaining space operations. The document states, in 
part, that sustained employment of space assets must 
be planned for to ensure sufficient replenishment of 
space-based resources is achievable when adapting to 
changes in circumstances dictated by mission 
operations. The doctrine clearly states that on-orbit 
support for space assets can be crucial to campaign 
success and that flexibility in space employment will 
require a combination of reserve platforms and launch 
systems, development of on-orbit spares, and the 
employment of both robotic and manned space 
platforms. Further, it cites that a space platform’s 
effectiveness can be significantly expanded by 
providing vehicles and crews to repair or modify the 
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platform, service it, or restock consumables such as 
fuel. 

USSPACECOM’s December 1990 Assured Mission 
Support Space Architecture (AMSSA) focused upon 
the follow key objectives: Robustness, flexibility, 

survivability, sustainability, availability, affordability, 
and normalization of support to space assets, and 
supportability of deployed space systems. To assure 
the United States has and retains ready access to space 
during peacetime and during times of increased global 
and regional tensions, the AMSSA study identified six 
specific initiatives, referred to as the “Big Six”, that 
must be improved and/or implemented: 
Communications; Navigation; Launch Capability; 
Command and Control; Satellite Control; and 
Integrated Logistics Support of space systems. It is 
the latter that addresses several tenets of the on-orbit 
support doctrine contained in AFM 1-1. 

FEASIBILITY OF ON-ORBIT SUPPORT 

Since the 1950’s, man has been launching and 
operating satellites in space. These spacecraft have 
had varied missions such as communications, 
navigational aids, experiments, weather, surveillance, 
and other military missions. The concept of on-orbit 
support dates from the first satellite failure. In the 
early days of space flight, the first concern was to 
merely get the satellite into orbit. Once that barrier 
was passed and orbiting satellites began returning 
data, interest turned toward increasing satellite 
performance. The strategy for maintenance of these 
spacecraft was reconfiguration by telemetry to correct 
individual element failures and abandonment after 
critical failure. Abandoned satellites are usually 
replaced with either a new satellite launched from the 
ground or a pre-positioned on-orbit replacement 
satellite. The concept of abandoning large and 
expensive satellites after failure is counterproductive 
in a time of reduced defense budgets. 

During the 1980’s, in partnership with private 
industry, NASA developed the Multimission Modular 
Spacecraft (MMS) design, a reusable bus containing 
three replaceable boxes that control spacecraft power, 
data handling, and attitude. Solar Max, launched on 
14 February 1980, was the first satellite to use the new 
design. After nine months of operation fuses failed in 
the attitude control subsystem module, rendering four 
of its seven instruments useless and compromising 
operations of the remaining three. In April 1994, the 
Space Shuttle Challenger was launched on a mission 


to capture and repair Solar Max. Although many 
unexpected difficulties arose during this mission. 
Solar Max was restored to service and a new era in 
orbital servicing and repair was launched. This 
mission provided the experience and know how 
necessary to capture and launch into their proper 
orbits the Palapa-B and Westar-6 satellites later the 
same year. These satellites had been placed into a 
wrong orbit due to a failure in their booster stage. 
Also, during this period, NASA designed and built the 
Hubble Space Telescope (HST) specifically to be 
maintained on on-orbit by astronauts through 
extravehicular activity (EVA). Should the space 
station become a reality, it is intended to be 
maintained on-orbit through a combination of EVA 
and the use of sophisticated robotics. 

By the end of the 1980’s numerous DoD and NASA 
studies and design concepts resulted in the 
establishment of a clear requirement for an on-orbit 
support capability. As a result, NASA and the 
Strategic Defense Initiative Organization (SDIO) 
formed a partnership to develop a Satellite Servicer 
System Flight Demonstration (SSS/FD) program. 
This was a joint effort to initiate a program to design, 
develop, and demonstrate a satellite servicing 
capability. A series of three flight demonstrations 
scheduled for 1993 through 1995 was planned. 
During the same timeframe, SDIO formulated a Space 
Assets Support Systems (SASS) implementation plan 
based upon existing and near-term technologies and 
capabilities. The plan, essentially a preliminary 
acquisition program plan, recommended that a SASS 
system program office be established to manage the 
design, development, and deployment of the SASS. 
National political and budgetary considerations forced 
the premature cancellation of the SSS/FD program 
and eliminated an opportunity to develop and 
demonstrate a very feasible, cost-effective alternative 
to the expensive abandon and replace concept 
currently used when spacecraft encounter failures, 
critical anomalies, or even fuel shortages. 

In addition to the satellites that were diverted from 
other strategic surveillance missions during Desert 
Storm, there are several communications satellites 
currently on-orbit that have drifted slightly out of 
their intended orbits. There is insufficient fuel 
remaining in these satellites to maneuver them back 
into the proper orbit for maximum utilization of their 
capabilities. The capability to refuel these satellites 
on-orbit would provide military commanders the 
flexibility to reposition satellites to meet theater 
contingency requirements without significantly 
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affecting the lifetime of the satellite. Additionally, 
survivability of the spacecraft could also be enhanced 
by an assured refueling capability in extending the 
satellite’s ability to perform elusive and evasive 
maneuvers to counter threats. 

NASA and DoD currently cosponsor an active 
committee under the American Institute of 
Aeronautics and Aeronautics (AIAA) that is 
developing necessary standards with the assistance of 
industry that, if implemented on future space vehicles 
or during block upgrades to existing space systems, 
could quickly produce the design and employment of 
on-orbit refueling ports or receptacles aboard many 
space vehicles to facilitate the safe, on-orbit transfer 
of fuel. 

CONCLUSIONS 

Many studies have been conducted which identified 
potential cost savings and other benefits to be realized 
through on-orbit support of space systems. There are 
wide differences in the amount of savings projected, 
sometimes even for the same space system, and the 
method of measuring the savings. The differences are 
due to the varied methodologies, assumptions, 
parameters used by the organizations conducting the 
studies. In addition to the potential cost savings, 
these studies have demonstrated that on-orbit support 
provides service life extension through a refueling 
capability, the capability to infuse new technology 
through the replacement of orbital replaceable units, 


and the ability to upgrade a system to meet expanded 
threats, etc. 

There does not appear to be any technological 
roadblock to on-orbit servicing. The driving 
technologies have been identified. An increased 
capability to service and maintain spacecraft on-orbit 
will continue to evolve through NASA efforts and 
independent research and development efforts of the 
aerospace industry. 

All of the studies examined concluded that there are 
several support capability needs which are key to the 
success of assuring mission support, and that these 
needs require positive commitment from senior Air 
Force and DoD decision makers. Most notable of 
these are the normalization of support of DoD space 
systems, modularity and standardization in space 
vehicle design, expanding DoD organic support, and 
the pursuit of on-orbit servicing capabilities to 
enhance satellite endurance. 
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Abstract 

The requirements for Space Technology are outlined 
in terms of NASA Strategic Plan. The national emphasis 
on economic revitalization is described along with the 
environmental changes needed for the new direction. 

Space Technology Interdependency (STI) is elaborated in 
terms of its impact on national priority on science, 
education, and economy. Some suggested approaches to 
strengthening STI are outlined. Finally, examples of 
Technology Roadmaps for Space Operations area are 
included to illustrate the value of STI for national 
cohesiveness and economic revitalization. 

Introduction 

The strategic approach to space technology 
development can be viewed as a set of interwound 
modules floating in the ocean of business environment 
(Figure 1). The vision, goals, objectives are formulated 
with customers and resources available in mind (Ref. 1). 
The business plan translates the detailed objectives into 
products and services. A critical part of the entire 
enterprise deals with identifying and implementing 
processes which provide the most efficient operation for 
die good health of tire business. Marketing is an integral 
part of ascertaining the viability of the products and the 
requirements for new products. 

The ultimate goal of the process is to enlarge tire 
customer base and/or increase the satisfaction level of 
customers. The correct process utilizes surveys, 
interviews, and other types of evaluations from the 
customers to develop a continuous stream of actions 
which should be undertaken to modify the strategy to 
provide the customer with the quality product, at the 
lowest price, and in the shortest possible time. The entire 
process has to be adjusted according to the changes in the 
business environment. The environment includes the 
overall health of the national economy, crisis situations 
caused by natural or human-made factors, status of 
competition, technological innovations, and any large 
shift in the preference of llie customers. 

This customer-driven process is die essence of die 
overall concept behind die development of space 
technology and its transfer to space projects/programs and 
die industry for commercial applications. The customers 
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are the NASA and DOD program offices and aerospace 
and non-aerospace industry. The environment to which 
overall strategies must be linked continues to change as it 
always has. According to the Electronic Industries 
Association, Washington, D.C., during the first half of 
1994, a record $48 billion worth of electronic products 
were exported, up 16 percent from the same period in 
1993; however, during the same period, imports of 
electronic goods rose 18 percent to $55.3 billion (Ref. 2). 
The products included are computers, peripherals, solid 
state devices, communications, electrochemical 
equipment, electron tubes, passive components, and 
consumer electronics. The national deficit and the 
balance of trade have made economic revitalization a key 
item for the USA. The Council on Competitiveness has 
shown that growth rates in real standard of living 
correlate strongly with the manufacturing productivity. 

For the period of 1972-1992, the US ranked sixth in the 
world in this comparison behind Japan, Italy, France, 
United Kingdom, and Canada Ref. 3). 

The role of technology in economic revitalization is 
widely recognized by academic, government, and industry 
communities. Recent studies conducted by the US 
National Critical Technologies Panel have identified 
applied molecular biology, distributed computing and 
telecommunications, flexible integrated manufacturing, 
electricity supply and distribution, materials synthesis and 
processing, microelectronics and optoelectronics, 
pollution minimization and remediation, software, and 
transportation as the nine industrial sectors particularly 
technology intensive and economically significant (Ref. 
4). Taken together, they represent major portions of the 
future growth of the US economy. In the recent past, US 
President William J. Clinton and Vice President Albert 
Gore, Jr., have issued two major policies titled, 
“Technology for America’s Economic Growth, A New 

• Global 



Direction to Build Economic Strength,” and “Science in 
the National Interest” (Refs. 5,6). 

The technology policy states that, ’Technology is the 
engine of economic growth.” Two-thirds of the 
productivity growth since this century’s major depression 
can be attributed to technological advances. Thus, this 
policy states that, “Investing in technology is investing in 
America’s future . . .’’(Ref. 5). 

The science policy draws its roots from President 
Clinton’s November 23, 1993 statement, “This country 
must sustain world leadership in science, mathematics, 
and engineering if we are to meet the challenges of 
today... and of tomorrow” (Ref. 6). Another idea behind 
the science policy is from the statement of Vice President 
Gore at the Forum on Science in the National Interest, 
February 1994, “Science reveals new worlds to explore, 
and by implication, new opportunities to seize and new 
futures to create.” 

Three new directions discussed in these policy 
documents are: (1) coordinated management of 
technology all across the government, (2) forging a closer 
working partnership among industry, federal and state 
governments, workers, and universities, and (3) 
redirecting the focus of US national efforts toward 
technologies crucial to today’s businesses and a growing 
economy. Laboratories managed by the Department of 
Energy, NASA, and the Department of Defense are being 
reviewed by the Administration with the aim of devoting 
at least 10-20 percent of their budgets to research and 
development (R&D) partnerships with industry. The 
| overall environment is changing to gravitate highly 
toward technology partnerships for the economic 
revitalization which includes educational, research, 
manufacturing, and marketing aspects of newly developed 
products and services. 


Space Technology Development 

The vision of NASA has been expressed in various 
ways in the past three decades. Perhaps the most 
encompassing statement comes from the NASA Strategic 
Plan which was issued in May, 1994, and reads as 
follows: “NASA is an investment in America’s future. 

As explorers, pioneers, and innovators, we boldly expand 
frontiers in air and space to inspire and serve America and 
to benefit the quality of life on earth” (Ref. 7). As a result 
of this vision , NASA has identified five strategic 
enterprises: 


- Mission to Planet Earth 

- Aeronautics 

- Human Exploration and Development of Space 

- Scientific Research 

- Space Technology 


NASA’s Strategic Functions provide capabilities 
’required by these enterprises. Specifically, these 
functions are (Ref. 7): 


- Transportation to Space 

- Space Communications 

- Human Resources 

- Physical Resources 

The interplay of the strategies, functions, and 
customers is detailed in the NASA Strategic Plan. Figure 
2 from this plan , shows this interconnectivity graphically. 

The Aeronautics and Space Engineering Board 
(ASEB) Commission on Engineering and Technical 
Systems of the National Research Council (NRC) 
reviewed NASA’s technology development for space 
science and issued a report in 1993. ASEB recommended 
eight technology areas with specific targets which are 
listed as follows (Ref. 8): 

- Advanced propulsion 

- Advanced Earth-to-orbit engines 

- Reusable cryogenic orbital transfer vehicles 

- High-performance orbital transfer systems for sending 
humans to Mars 

- New spacecraft propulsion systems for solar system 
exploration 

- Humans in space 

- Radiation protection 

- closed-cycle life support systems 

- Improved EVA equipment 

- Autonomous system and robotic augmentations for 
humans 

- Human factors research 
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- Autonomous systems and robotics 

- Lightweight, limber manipulators 

- Advanced sensing and control techniques 

- Teleoperators 

- Space power supplies 

- 100 Kw nuclear power source 

- Materials and structures 

- Advanced metallic materials based on alloy synthesis 

- “Hot” structures to counter reentry heating 

- “Trainable” control systems for large flexible 
structures 

- Information and control 

- Autonomous on-board computing system 

- High-speed, low-error rate digital transmission over 
long distances 

- Voice/video communications 

- Spacebome tracking and data relay 
-Equipment monitoring technology 

- Ground data handling, storage, distribution and 
analysis 

- Advanced sensor technology 

- Large aperture optical and quasi-optical systems 

- Detection devices and systems 

- Cryogenic systems 

- In-situ analysis and sample return 

- Supporting technologies 

- Radiation insensitive computational systems 

- High-precision attitude sensors and axis transfer 
systems 

The Space Technology Enterprise has identified the 
following activities in support of the national needs 
( Ref. 9): 

Space Technology Enterprise 
National Need Activity 


Fundamental Science - Materials Research 

- Remote Sensing 

National Security - Advanced Space 

Transportation (AST) 

- Space Communications 

- Small Spacecraft 

Technology 

Environmental Protection - Remote Sensing 

- Small Spacecraft 

Technology 

Industrial Competitiveness - Space Processing 

- Commercial Network 

- Advanced Integrated 

Technology Program 

- Technology Reinvestment 

Program 

-AST 

Space Exploration - Space Research and 

and Aeronautics Technology 

Flight experiments support each of the NASA Space 
Technology Enterprise Activities. In parallel with these, 
there is continued and new emphasis on space technology 


transfer programs including the Small Business 
Innovation Research (SBIR) program. The vision of the 
NASA Space Technology Enterprise (STE) is to pioneer 
with industry the development and use of space 
technologies to secure national economic 
competitiveness, to support space missions, and to 
provide low cost, highly operable access to space. The 
mission of STE is to stimulate the development and 
transfer of space technology to promote the creation of 
new knowledge, jobs, products and industries and their 
strategy is to maintain customer focus; provide space 
critical, world class capabilities; and leverage our 
resources. This includes inter-center collaborations, 
interagency collaborations, and private industry 
partnerships. Indeed, NASA offers unique opportunities 
for scientific research, technology development, and 
innovative methodologies for academic and research and 
technology institutions. 

The space characterized by open space in terms of 
distance, voids, debris, gravity, electricity, magnetism, 
atmosphere, particles, temperature, acoustics, time, 
seismic activity, and electromagnetic radiation, provide a 
unique laboratory environment which can be 
economically used for experimentation and 
manufacturing of certain products. NASA's facilities and 
personnel offer a unique resource to other agencies, 
universities, and industry for developing partnerships. In 
addition, NASA has played an important role in the 
identification of new research areas and technology 
development needs because of its mission and objectives. 

Many of the fundamental research and technology 
areas which have been identified by NASA as priority 
items continue to be special emphasis areas in the 
Department of Defense and several other agencies. This 
overlap in technology development is significant and 
needs to be addressed in overall national interest of 
avoiding duplication. 

Space Technology Interdependence 

The Space Technology Interdependency Group 
(STIG) was established in May, 1982 to identify and 
promote the pursuit of new opportunities for cooperative 
relationships between NASA and the US Air Force 
Systems command (AFSC). 

In addition, STIG is chartered to monitor ongoing 
cooperative activities and identify areas of overlap and 
duplication. The Air Force responsibility now is located 
in the Materiel Command after the reorganization of the 
Air Force became effective in 1991 . The goal of S 1 IG is 
to provide advocacy, oversight, and guidance to facilitate 
and encourage cooperative development programs and to 
avoid duplication of effort and resources on space 
technology activities. Three categories of programs have 
been defined by STIG to characterize interaction The 
dependent program is the one in which a single set or 
subset of mutually constructed management, shared 
resources, and strong agency executive management 
support. An interdependent program is one in which 


some degree of overlap is stated in the agency program 
and/or technical goals, as outlined in a jointly developed 
program plan. It is assumed that there are complementary 
synergistic results beneficial to the participating agencies. 
Independent programs are conducted by one agency, with 
minimal or no cooperation from other agencies. In the 
past five years, US Army, US Navy, Department of 
Energy (DOE), Advanced Research Projects Agency 
(ARPA), Ballistic Missiles Defense Organization 
(BMDO), and National Oceanic and Atmospheric 
Administration (NOAA) have joined STIG. 

The STIG was organized and is implemented by 
direction from a Steering Committee. The AF materiel 
Command Deputy Chief of Staff for Technology and the 
NASA Associate Administer for the Office of Space 
Access and Technology serve as Co-chairpersons and are 
responsible for designating members to the Steering 
Committee. The Steering Committee currently has 
members from the Army, Navy, BMDO, ARPA, and 
DOE Steering committee members are from the 
Headquarters executive staff to provide technical 
expertise needed for direction and evaluation or programs. 

The STIG program is implemented through eight 
technical committees. These committees are established 
by the Steering Committee (SC). The members are 
selected from participating field centers and laboratories. 
The co-chairpersons for the technical committees are 
nominated by members of the JSC and approved by SC 
co-chairpersons. We will briefly describe the 
implementation strategy for the STIG Operations 
Committee (SOC) to illustrate the organization and 
products that come from each of the STIG technical 
committees. 

The SOC is co-chaired by Dr. Kumar Krishen of the 
NASA Johnson Space Center and Dr. Richard Miller of 
the US AF Armstrong laboratory. There are five 
subcommittees under SOC on the Robotics and 
Telepresence, Automation and Intelligent Systems, 

Human Factors, Life Sciences and Avionics. These five 
subcommittees are jointly co-chaired by technical experts 
from the two organizations, NASA and USAF. The 
membership of the SOC includes Army, Navy, DOE and 
BMDO in addition to NASA and the USAF. The SOC 
has 65 members. The members of SOC were nominated 
by their laboratories, research centers, or organizations 
and are approved by SOC co-chairpersons and the STIG 
Steering Committee. The SOC conducts two meetings on 
a yearly basis to: (1) review operations research and 
technology (R&T) plans, resources and progress within 
NASA, DOD, and DOE; (2) develop and maintain list and 
descriptions of current interdependent programs and 
encourage and recommend future interdependent 
programs; and (3) develop and review technology 
roadmaps for interagency projects. One key area of SOC 
work involves facilitating communication of R&T results 
in the operations area across agencies and various centers 
within these agencies involved in the operations R&T. 
This technical interchange is facilitated through STIG 
Operations, Applications and Research (SOAR) 
Symposium and Exhibition. 


This author has participated in the STIG for a number 
of years. Furthermore, the author maintains very active 
interface with academia, industry, and R&T agency of the 
State of Texas. On the basis of many years of experience, 
the author proposes the following vision for Space 
Technology Interdependency (STT): “Create and promote 
STI infrastructures to encourage and coordinate 
cooperative projects in R&T for mutual benefits to the 
organizations involved.” The benefits of STI are 
numerous and can be summarized as follows: 

(1) increasing interagency communications at all levels; 

(2) creating national technology cohesiveness through 
interaction with industry and academia; (3) sharing of 
expertise and facilities across agencies, industry, and 
educational institutions; (4) avoiding undesired 
duplication and reinventing through sharing of lessons 
learned; (5) developing cost-effective approaches through 
interdependent programs; (6) facilitating the identification 
of technology requirements for specific applications; and 
(7) creating an environment to gain a substantial edge in 
international competitiveness through technology transfer. 

The STI management infrastructure should be easily 
implementable with a minimum impact to cooperating 
organizations. Furthermore, such a structure should be 
least affected by frequent reorganizations of the 
cooperating agencies/organizations. One such 
organization is proposed in Figure 3, and is patterned after 
the STIG discussed earlier in this paper. 

Headquarters 

of Agencies/ 



Figure 3 - Proposed STI Management Infrastructure 
Operations Technology Roadmaps 

As part of the Space Technology Interdependency 
Group (STIG) key activities, NASA and the Air Force are 
developing technology roadmaps aimed at providing a 
mechanism by which greater visibility and coordination 
can be achieved in U.S. interdepartmental activities and 
advances in the area of space technology development. 
These technology roadmaps are at a critical stage of 
development and will be a vital step to the 
implementation phase of technology transfer and future 
commercialization by private industry, as well as 
improving upon our own government operations. The 
roadmaps currently being developed and implemented are 
a coordinated effort of all the agencies involved in the 
space technology interdependency. 
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The SOC has compiled more than 20 roadmaps in its 
areas of responsibility. Typically a roadmap provides 
vision and objectives for a particular technology thrust. It 
identifies involvement of various agencies in research, 
design, development, demonstration, and flight 
experiment for the technology thrust. Key persons 
responsible for the interdependency management of 
various phases of development are identified. Estimated 
resources and schedule for the completion of the work are 
also provided. Details of anticipated milestones are 
provided along with a brief description of the goals to be 
achieved. These roadmaps are in their initial draft 
preparation stage. We are providing two such roadmaps 
in Figures 4,5 Robotic Exploration Vehicles and Human 
Workload Modeling. 

It is crucial to emphasize that these roadmaps are 
being revised to reflect new budgetary data and are 
merely presented here to illustrate the usefulness such a 
resource for our National technology development. This 
author believes that such roadmaps should be revised on a 
yearly basis to accommodate new budgetary data and 
strategic emphasis. Furthermore, publication and 
distribution of such roadmaps can provide the catalytic 
effect for accelerating partnership by various 
organizations wanting to explore avenues of using 
interdependent efforts to achieve their goals. In the least, 
just to prepare these roadmaps and to review the 
achievements periodically will result in many government 
agencies and organizations getting together and, therefore, 
forging meaningful interdependencies. 

Conclusions 

The Space Technology Interdependency (STI) is a 
manageable task since space technology needs are 
relatively understood and there is a mechanism to 
periodically update the list of high priority space 
technologies (Ref. 10). The STI would facilitate 
identification of technology requirements with realistic 
specifications. The foremost requirement for the 
management structure for STI should be its ability to 
provide motivation to personnel to implement and 
promote cooperative efforts. Communications should be 
effective at all levels and decisions should incorporate 
both top-down and bottom-up inputs. There should be 
clear guidelines for measurement of success. The 
implementation of successful management infrastructure 
provides a challenge. It should be a process oriented and 
flexible approach. There should be emphasis on team 
work, and not on preconceived results. Most important, it 
should incorporate rewards and incentives for those who 
produce desirable results. 
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ROBOTIC EXPLORATION VEHICI FS 
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VISION: To develop autonomous vehicles operating in harsh terrains and capable of 

reconnaisance, surveillance, data collection, and scientific experiments 
OBJECTIVE: To augment soldiers in the field by enhancing autonomous search and 

— d gSUQY Capability and to enable remote planetary exploration missions. 
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DOD Key Personnel: 
AF 

Name: Erf Alexander 
HQAFCESA/RA 

Address. Tynd#i ^ FL 
Phone : 904/283-3705 


Army 

Chuck Shoemaker 
AMSAL-WT-WG 
Aberdeen Proving Ground MO 
410/278-8809 



NASA CENTERS: NASA CODE C/JPL 


NASA Key Personnel: 

Dr. Charles Wetsbin/JPL 
Mail Stop 1 80-603 
Pasadena, CA 91 109-8099 


lave Strip, Sanda Lab, DOF, 
505/844-3962 
Joe Herndon, ORNL, DOE, 
615/576-0119 
Capt. Pad V. Whalen, USAF 
AL/CFBA, WPAFB 513/255-3671 


DOD/OTHER AGENCIES; ARPA, NAVY (EOD), DOE (ORNL, SA NDIA), ARMY (TACOM), AF (AFMC) 

FUTURE PLANS' Auton ° fnous navigaton in unstructured I' ^ v ifonmen ' -, tavIr-bandWidth communications and 

control, pattern recognition, miniature actuators, etc. Stereo vision from JPL developments 
will be used in ARPA Unmanned Ground Vehicle (UGV) project and by AF unexploded ordnance 
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TECHNOLOGY GOAL: 


To develop autonomous vehicles capable of operating In harsh 
terrains and capable of reconnaisance, surveillance, data 
collection, and scientific experiments. 


FY 9,4 



DOE Demonstrate 
Autonomous 
Site Survey 


1 Km traverse of 
Mars MicroRover 
NAVY EOD Demo 


AUTONOMOUS MARS 
ROVER VEHICLE 


Autonomous UXO 
(Unexploded Ordnance) Clearing 


Fig. 4. Robotic Exploration Vehicles 
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HUMAN WORKLOAD MODELING 


(VISION: To coimi'bu't e'to'TUe *dwe'k>pment "ofThe scientific and technological foundations for sale and productive) 

I human presence in space. 

OBJECTIVE: To icce» the utility of Ink network modeling for jtudying: Function .Hoc.tion stretegles; effect) of 

temporal, biological and environmental stressors on human perfcxmance; 0-g and partlal-g effects on human 
performance; psychomotor, perceptual, & information-processing capabilities of the human operator; and 
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[TECHNOLOGY AREA: 
Human Factors 
btSCIPLINE: 


Life Sciences 



NASA CENTERS: NASA-Johnson Space Center/Flight Crew Support Division 


DOD/OTHER AGENCIES: 


FUTURE PLANS: 


^ - None. 

The task network simulations developed w# lead to a number of products that will be applied to future 
task networks simulations of ths workload likely to be experienced during future missions. Specifically, 
the task netwotk simulations wfll form the foundation for Identifying overload conditions A developing 
UgafrBQtol radi o ing wnridnarf during *naca mllS l flni 
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TECHNOLOGY GOAL; To provide mission planners with a method for optimizing allocation 

of mission tasks; optimizing formulation of timelines, schedules and 
equipment design; and assessment of the feasibility of proposed missions. 


v EXECUTION 
INVALIDATION 



A deformation will be made 
of the degree to which the 
task network model is a 
reasonable representation 
of the amount of workload 
likely to be induced by 
the task selected for 
analysis. 


EARLY 
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A total of 10 subjects from the aerospace 
community will be presented with a description 
of an EVA/IVA task In random order for each of 
the four workload channels. For each task, 
subjects will be assigned a numerical estimate 
that reflects the amount of workload likely to 
imposed by the task. Similar estimates will then 
be made for subsequent tasks. 

Development of the model will involve translation of the operational 
sequence diagrams Into a computer simulation that permits anlysis of 
the workload likely to be induced by the operation. 

During this phase, a mission operation will be selected for analysis. The selecton process 
will begin with an in-depth examination of relevant documentation. The approach will 
ensure efficient extraction of task Information and will establish the organization of the 
task analysis, as well as the functional flow of the task to be modeled, analysis of the 
operations performed will be completed In the form of operatonal sequence diagrams 
illustrating the steps that crewmembers must accomplish to complete the operation. 

Fig. 5. Human Workload Modeling 





Background 

The Human Workload Analysis program of investigation is a joint effort between NASA/ Johnson 
Space Center and Brooks AFB. The center of overall responsiblity for the implementation of 
the project is the Crew Interface and Analysis Section of the Flight Crew Support Division of 
NASA-JSC. 

Major Milestones 

USAF Cooperative/Human Workload Analysis Project is a 3-year, 4-phase program of investigation. 

FY95 - Front-End Analysis 

FY96 - Workload Component Scale Development 

FY97 - Execution and Model Validation 

Management Approach 

The NASA-JSC principal Investigator, in conjunction with the Human Interfaces Department at Lockheed Engineering and Sciences 
Co. (LESC), supports the overall effort for JSC. The Principal Investigator will report directly to the Flight Crew Support 
Division. Under the direction of the NASA-JSC Technical Monitor, the Engineering Supervisor of the Human Factors and 
Ergonomics Laboratory (HFEL) and the human workload analysis lead will be responsible for completion of all deliverables. 

Technical support is provided by Brooks AFB, Armstrong Laboratories, in the form of implementing the workload models in 
computer models. The Air Force provides expertise in workload modeling using SAINT, a network analysis tool This predicts 
workload on any of several channels. The AF has expertise in programming in SAINT, and takes the models developed by NASA 
and implements them. The programs are transmitted electrontcaRy to be run on NASA equipment. 

The project is managed by the NASA technical manager, with Lt. Mitcha providing Air Force management of budget, manpower, 
and work as assigned by NASA. All funding comes from NASA's Office of Life and Microgravity Science and Applications, and funds 
are transferred to the Air Force to cover their efforts. 

End Products/Users 

The task network workload modeling tool currently under development will provide mission 
planners with a method for : 

1 ) optimizing allocation of mission tasks, 

2) optimizing formulation of timelines and schedules 

3) optimizing equipment design, and 

4) assessment of the feasibility of proposed missions 
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Major Deliverable And Periods Of Performance 

r twse ' , i; , : f~ Months After Contract Award 
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I Front-End Analysis 


II Model Development 

III Workload Component 

Scale Development 


IV Execution & Model Validation 
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Final X 
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Fig. 5 (cont.). Human Workload Modeling 


AIAA-95-0934-CP 


The Evolution of 
Mission Architectures for 
Human Lunar Exploration 

S.F. Everett 

University of Houston Clear Lake 
Houston, Texas 




6 . 

0/0 OOG 


I. Abstract 

Defining transportation architectures for the human 
exploration of the Moon is a complex task due to the 
multitude of mission scenarios available. The mission 
transportation architecture recently proposed for the 
First Lunar Outpost (FLO) was not designed from care- 
fully predetermined mission requirements and goals, 
but evolved from an initial set of requirements, which 
were continually modified as studies revealed that 
some early assumptions were not optimal. This paper 
focuses on the mission architectures proposed for FLO 
and investigates how these transportation architec- 
tures evolved. A comparison of the strengths and 
weaknesses of the three distinct mission architectures 
are discussed, namely (1) Lunar Orbit Rendezvous, (2) 
staging from the Cislunar Libration Point, and (3) direct 
to the lunar surface. In addition, several new and revo- 
lutionary architectures are discussed. 

II. Introduction 

Since the inception of the space age, transporta- 
tion nodes, such as parking orbits about the Earth and 
Moon, have been utilized to maximize mission planning 
flexibility while minimizing program risks. However, 
defining transportation architectures for the human 
exploration of the Moon is a complex task due to the 
multitude of mission scenarios available. 

The mission transportation architecture currently 
baselined for the First Lunar Outpost (FLO), was not 
designed from carefully predetermined mission 
requirements and goals, but evolved from an initial set 
of requirements, which were continually modified as 
studies revealed that some early assumptions may not 
have been optimum. This paper will discuss the mis- 
sion architectures currently under consideration for 
FLO and will investigate how these transportation 
architectures evolved. 

There are three distinct mission architectures, (1) 
Lunar Orbit Rendezvous (LOR), (2) staging from the 
Cislunar Libration Point (CLP), and (3) direct to the 
lunar surface (Lunar Direct). These architectures are 
defined by how the vehicle(s) arrival at and departure 
from the Moon. Subsets of these three architectures 
are defined by whether the vehicle(s) depart from a 
space station and whether the crew returns to a space 


station, splashes down, or lands propulsively on the 
ground. 

A literature search revealed literally hundreds of 
papers involving various aspects of these three archi- 
tectures and their numerous subsets. However, only a 
few papers attempted to compare one architecture to 
another, and those only compared a few specific 
parameters. One study was found which compared all 
three architectures; but it was based on a specific set 
of predetermined assumptions, and was not formally 
published. 

III. Background 

On 25 May 1961, President Kennedy committed 
the United States to the goal of landing men on the 
Moon by the end of the decade. 1 That goal was 
achieved when Apollo 11 placed Americans on the 
Moon on 20 July 1969. 2 The United States performed 
five more successful missions to the Moon between 
1969 and 1972, using a mission transportation archi- 
tecture called Lunar Orbit Rendezvous or LOR. 1 Some 
useful Apollo statistics are listed in Table 1 . Note that all 
were brief, near equatorial, front side missions, with 
surface stay times between two and three days. 


Table 1 : Apollo Landing Sites 4 


Apollo 

# 

Date 

d/m/yr 

Latitude 

Longitude 

Stay 
Time hr 

11 

7/20/69 

(landing) 

00° 41’ 15” 
N 

23° 26’ 00” 
E 

21 

12 

11/19/69 

(landing) 

03°11’51” 

s 

23° 23’ 08” 
W 

31 

14 

1/31/71 

(launch) 

03° 40’ 24” 
S 

17" 27’ 55” 
W 

33. 

15 

7/26/71 

(launch) 

26° 06’ 03” 

N 

03° 39’ 10” 
E 

66 

16 

4/16/72 

(launch) 

08° 59’ 29” 
S 

15° 30’ 52” 
E 

71 

17 

12/7/72 

(launch) 

20" 09’ 55” 
N 

30° 45’ 57” 
E 

74 


Copyright @1994 by S.F. Everett. 
Published by AI AA with permission. 
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An overview of the LOR mission Architecture uti- 
lized by the Apollo missions is shown in Figure 2. Direct 
ascent from the ground to Low Earth Orbit (LEO) and 
Trans-Lunar Injection (TLI) were performed by a Sat- 
urn-5 rocket. The trajectories were designed to pass in 
front of the Moon, allowing the command module to 
perform the Lunar Orbit Insertion (LOI) burn on the 
back side of the Moon if all systems were performing 
well, placing the vehicle in Low Lunar Orbit (LLO). 1 

The vehicle consisted of two pressurized capsules, 
the command module, and the lander. The command 
module housed the crew of three on the outbound and 
return legs of the mission, and performed a hyperbolic 
direct reentry at the Earth, splashing down in the 
ocean. The lunar lander consisted of two stages. The 
first performed the de-orbit and descent burns, taking 
two astronauts to the surface, while the third astronaut 
remained in LLO with the command module. After a 
one to three day stay on the lunar surface, the upper 
portion of the lander performed the ascent burn and 
rendezvoused with the command module in LLO. The 
lower stage remained on the lunar surface, while the 
upper stage was expended in LLO, meaning it was left 
behind were its orbit would decay causing it to crash 


into the lunar surface. 

On 20 July 1989, on the 20th anniversary of the 
Apollo 1 1 landing, President Bush challenged America 
to go, “back to the Moon, back to the future. And this 
time, back to stay.” 2 

The NASA Administrator at that time, Richard H. 
Truly, quickly formed a task force to perform a three- 
month study of the human exploration of the Moon and 
Mars. 5 In November of 1989, the task force published 
the “Report of the 90-Day Study on Human Exploration 
of the Moon and Mars”, 5 or the '90-Day Study’ as it 
was dubbed. The majority of subsequent studies 
involving lunar exploration architectures evolved from 
this report. 

IV. Evolution of Lunar Exploration 
Mission Architectures 

The lunar mission architecture outlined in the ‘90- 
Day Study’ was derived from the Apollo architecture, 
but included a number of important changes. There- 
fore, a summary of their findings and assumption is 
important. 
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Summary of the 90-D av Study 5 

The team, faced with a short-term deadline, chose 
an overall architecture they knew would work, Lunar 
Orbit Rendezvous. However, the goal of the return to 
the Moon is to achieve a permanent presence there, 
which requires much longer stay-times, and thus a sur- 
face habitat and additional cargo. The initial habitat 
was required to support a 30-day stay. To achieve this, 
the team chose to split the mission into two parts, a 
cargo mission and a piloted mission. An autonomous 
cargo vehicle delivers a surface habitat and cargo to 
the lunar surface prior to the piloted mission. 

The vehicle design consists of two pressurized 
modules as did Apollo, a Lunar Transfer Vehicle (LTV) 
and a Lunar Excursion Vehicle (LEV) (see Figure 3). 



Fig. 3. ‘90 Day Study’ Vehicle Configuration 


The LTV is a reusable ‘tug’ that carries a crew of 
four and their cargo to the Moon and back, and trans- 
ports the LEV to low lunar orbit. The assumed payload 
capability of the transfer vehicle is 33 metric tons or 16 
tons plus the crew and excursion vehicle. The fuel cho- 
sen for the vehicles was liquid oxygen / liquid hydro- 
gen. 

The LEV is similar to the Apollo lander, an expend- 
able two-stage lander. The first stage performs the 
descent to the lunar surface and is left behind. The 
second stage performs the ascent, rendezvous with 
the transfer vehicle, and is expended in LLO. 

An additional departure from the Apollo architec- 
ture was the choice to assemble and launch the vehicle 
from Low Earth Orbit (LEO) near Space Station Free- 
dom (SSF), rather than perform a direct ascent from 
the Earth’s surface. Furthermore, a free-return trajec- 
tory was required for the piloted missions. An overview 
of this mission architecture is shown in Figure 4. 

The mission begins with a translunar injection 
maneuver (TLI) performed by the LTV at a safe dis- 
tance from the space station. A lunar orbit insertion 
(LOI) maneuver is performed upon arrival at the Moon. 
The LEV separates from the LTV and descends to the 
lunar surface with the crew and payload. 

After a specified stay time, the Earth return leg of 
the mission is initiated with an ascent-rendezvous 
strategy designed to transport the crew and payload (if 
any) to the LTV waiting in lunar orbit. At this point, sev- 
eral options are available. The LEV can be brought 



Fig. 4. ‘90-Day Study’ Mission Architecture 
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back to the space station to be refurbished and reused. 
This option tends to significantly increase the initial 
mass in low Earth orbit (IMLEO) required to perform 
the mission. A second option is to leave the LEV in 
lunar orbit for reuse on the next mission. This increases 
mission planning complexity due to the additional ren- 
dezvous requirements placed on the following mission. 
In addition, long term stability of the lunar orbit is a non- 
trivial issue due to the complex selenopotential effects. 
This option also restricts landing site accessibility to 
those latitudes which are below the inclination of the 
LEV’S orbit. A third option also enables LEV reusability 
but requires an in situ propellant infrastructure on the 
lunar surface. This requires storing the LEV on the 
lunar surface and taking advantage of lunar oxygen to 
reduce propellant transportation requirements from 
Earth. While an attractive option if lunar oxygen can be 
produced efficiently, it was not considered in this study 
due to the a priori requirements for a lunar base infra- 
structure. The fourth option utilizes an expendable LEV 
strategy, which has the effect of reducing both the initial 
mass in low earth orbit and the mission complexity, and 
was therefore chosen by the ‘90-Day’ team. The LTV 
performs a transearth injection maneuver (TEI) which 
places it on an Earth return trajectory while leaving the 
expendable LEV in lunar orbit. An Earth aerocapture 
maneuver then places the LTV in an orbit whose apo- 
gee is ideally suited to a space station rendezvous. 
When the LTV is near apogee, a perigee raise maneu- 
ver, referred to as Earth orbit insertion (EOI), is per- 
formed. This maneuver places the LTV in a circular 
orbit compatible with the space station. The final ren- 
dezvous sequence completes the mission. The LTV 
and the aerocapture heat shield are refurbished at the 
space station for reuse on subsequent missions. 5 

Alternate Mission Modes 

Following the ‘90-Day Study', numerous studies 
were performed to assess their design. Many of the 
studies unearthed problems with the assumed mission 
architecture. Some of the key problems are discussed 
below. 

One of the first aspects of the ‘90-Day Study’ archi- 
tecture that was analyzed was the constraint of a free- 
return to the space station. Studies showed that oppor- 
tunities for free return trajectories that would return the 
vehicle to the station are very rare, due to the complex 
geometry of the Earth-Moon system combined with a 
regressing station orbit. Opportunities during the eigh- 
teen-year lunar cycle occur at best once every few 
months, and in the worse years, are not available at all. 
Free-returns are available once every 6 to 1 0 days if 
the vehicle is not constrained to return to the station; 


however, free-returns are only available when targeting 
for near-equatorial lunar sites, regardless of where the 
vehicle departs from or returns to. 6 This was identified 
as a problem by a lunar site selection committee, which 
indicated global access is desired by the scientific com- 
munity. 7 

Other studies showed that for non-equatorial mis- 
sions, which must have higher inclination orbits, the 
orbits regress up to a degree per day. This, coupled 
with the rotation rate of the moon (about 13.2 degrees 
per day) can result in surface wait times of up to 14 
days before the excursion vehicle can lift off to rendez- 
vous with the transfer vehicle. In addition, high inclina- 
tion orbits may only have minimum energy transfers 
available twice per month, and these opportunities may 
not coincide with the required alignment for a return to 
the regressing space station orbit. 8> 9 

As a result of these and other studies, two new 
mission architectures were identified as worthy of 
study, lunar direct and high lunar staging . 10 

Lunar Direct 

Under the lunar direct transportation architecture, 
the entire vehicle descends to the lunar surface. No 
components remain in lunar orbit as opposed to the 
LOR architecture. This eliminates orbit rendezvous, 
simplifies mission planning, removes imposed surface 
stay times, allows global access, and requires the 
development of only one pressurized vehicle. However, 
the vehicle mass must be much higher than that of the 
LEV and LTV, since it must carry all of its Earth-return 
fuel down to the lunar surface and back. This mass 
increase corresponds to a larger IMLEO, which implies 
the need for either larger lift vehicles or more launches 
and assembly in LEO, when compared to the LOR 
architecture. In addition, the sensitivity of total vehicle 
mass to crew module mass limits the cargo capability 
of the lander, meaning it would be very expensive in 
terms of both mass and dollars to build a lander capa- 
ble of staying a month or more at a time. Thus, an 
autonomously delivered surface habitat could be 
required, perhaps necessitating another launch. 10 

High Lunar Staging 

The high lunar staging architecture is, in general, 
just a variation of lunar orbit rendezvous. By staging far 
from the Moon’s gravity well, larger plane changes can 
be made with reasonable propellant use, allowing glo- 
bal access; something not feasible from low lunar orbit. 

The payload capability is greater than that of the 
direct mode, but somewhat less than that of the LOR 
option. However, many of the phasing problems asso- 
ciated with the low LOR architecture apply to the high 


American Institute of Aeronautics and Astronautics 


143 



Fig. 5. Lunar Direct Mission Architecture 


LOR as well. That is, with the exception of one special 
high-altitude staging point, the cislunar libration point. 
Staging from the cislunar libration point, alleviates 
many of the phasing problems associated with lunar 
orbit rendezvous, because it does not actually orbit 
about the moon, but remains fixed above the lunar sur- 
face, at a point between the Earth and Moon. 10 

The cislunar libration point (CLP) staging scenario 
allows for a smaller lander than the direct mode, while 
providing moderate payload capability with a lower ini- 
tial mass in LEO. It allows global access and a return 
any time from the surface. In addition, free returns on 
the outbound transfer are always available. 8 

Cislunar Libration Point Staging 

Libration point locations are found as special solu- 
tions of the restricted three-body problem which is 
defined as follows: two mass points m , and m 2 of 
arbitrary finite mass revolve in circular orbits about their 
center of mass under the influence of their mutual grav- 
itational attraction. A third body (m 3 ) of infinitesimal 
mass (that is it does not influence the motion of the pri- 
maries m l and m 2 ) moves under the gravitational 
influence of the primaries. The “problem" is to describe 
the motion of m 3 , which is not required to move in the 
plane of motion of the primaries. All motion takes place 
in a rotating cartesian system whose origin is the cen- 
ter of mass. The x-axis is along the line connecting 
and m 2 and the z-axis is normal to the plane of motion 
of m x and m 2 . For this analysis, the larger of the two 


masses (Earth) is denoted by m { and is separated 
from the smaller mass (Moon) denoted by m 2 , by a 
distance d. 11 

This problem has no general analytical solutions as 
does the more familiar two-body problem. However, it 
does have some very special solutions which are quite 
useful. There are five stationary points or solutions for 
this problem. They are depicted in Fig.6 for the Earth- 
Moon system. 
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6. Libration Points in the Earth-Moon System 11 


‘Stationary’ means that an infinitesimal mass would 
have no motion in the rotating system if placed at the 
point with zero initial velocity. The stationary points will 
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be referred to as libration points in this paper; although 
they are also referred to as equilibrium, Lagrangian 
and Eulerian points. Three of these libration points, 
known as the collinear points, lie on the Earth-Moon 
line. In this paper, these are referred to as “translunar" 
for Lj , “cislunar” for L 2 and “transearth” for L 3 . The 
other two points (L 4 and L 5 ) form equilateral triangles 
with the primaries and are called the Lagrangian 
points. 11 

A stability analysis reveals that the collinear libra- 
tion points are always unstable. This fact suggests that 
station keeping would be required to maintain a satel- 
lite at the collinear points even in the idealized environ- 
ment of the restricted three-body world. The equilateral 
points are found to be stable provided the mass param- 
eter (m 2 / (m, + m 2 ) ) is less than 0.0385. This is true for 
the Earth-Moon system, whose mass parameter is 
approximately 0.01215058. 11 

The CLP strategy requires twice as many propul- 
sive maneuvers as the LOR strategy (excluding ascent 
and descent) and therefore a new naming convention 
was developed. The additional maneuvers occur at the 
CLP where the LTV is stored, while the crew uses the 
LEV to explore the Moon. The naming convention is 
presented in Table 2, with the analogous LOR maneu- 


ver acronyms listed for comparison. An overview of the 
CLP strategy is depicted in Figure 7. 


Table 2: CLP NAMING CONVENTIONS 


Maneuver 

Definition 

Correspon 
ding LOR 
Maneuver 

'ECU 

Earth-Cislunar 

Injection 

TLI 

CLOI-1 

CisLunar Orbit 
Insertion-1 


CLLI 

CisLunar-Lunar 

Injection 

LOI 

LOI 

Lunar Orbit Insertion 


LCLI 

Lunar-CisLunar 

Injection 

TEI 

CLOI-2 

CisLunar Orbit 
Insertion-2 


CLEI 

CisLunar-Earth 

Injection 


EOI 

Earth Orbit Insertion 

EOI 


The CLP scenario is similar to the LOR strategy 
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with the exception of the four additional propulsive 
maneuvers required to stop at and depart from the 
CLP. On a typical mission, the LTV would depart the 
space station with the ECU maneuver and insert at the 
CLP with the CLOI-1 maneuver. After separating from 
the LTV, the LEV and crew leave the CLP by perform- 
ing the CLLI maneuver and insert into an intermediate 
low lunar orbit with the LOI maneuver. When the proper 
landing site phasing is attained, the LEV descends to 
the lunar surface, leaving nothing in lunar orbit. Another 
option is to land directly on the surface without stop- 
ping in an intermediate lunar orbit. However, this gen- 
erally requires larger changes in velocity (AV), due to 
increased gravity losses. Landing site exclusion zones 
also exist when using this scenario. 12 These zones 
can be eliminated with a three burn strategy, but this 
complicates the mission planning, and can increase 
the total AV requirements. The return scenario uses a 
similar strategy by ascending to an intermediate low 
lunar orbit before injecting into a CLP transfer orbit with 
the LCLI maneuver. The CLOI-2 braking maneuver at 
the CLP permits the LTV/LEV rendezvous. The crew 
transfers to the LTV and returns to the space station 
using an aerocapture technique similar to the LOR 
strategy. This is accomplished using the CLEI and EOI 
maneuvers. Notice that, unlike the LOR strategy, the 
LEV is left at the CLP for reuse on subsequent mis- 
sions. This is possible because the rendezvous compli- 
cations associated with leaving the LEV in lunar orbit 
are eliminated. 

Stability analysis has shown that station keeping 
near the unstable CLP is very little, on the order of one 
meter per second per year. 12 Thus, storage of the LEV 
at the CLP would not be a problem from a storable fuel 
standpoint, but might be a challenging autonomous 
guidance and navigation problem. 

V. Earth Return Options 

Another factor which complicates the choice of 
architecture is how the crew is returned to the Earth’s 
surface. There are three basic Earth return scenarios 
available for each of the modified mission architec- 
tures: (1) capture the crew cab into LEO either propul- 
sively or via an aerobrake maneuver and rendezvous 
with either the space station, space shuttle, or some 
other form of crew return vehicle in low Earth orbit 
which would transport the crew to the surface, leaving 
the crew habitat in LEO to be refurbished or expended, 
5 (2) capture the crew cab into LEO and land either 
propulsively on dry land, as the cosmonauts do, or 
glide to a horizontal landing as the shuttle does, 15 or 
(3) return to Earth on a hyperbolic trajectory, perform a 
direct entry, splash down ’Apollo-style’ in the ocean, 
and be recovered by ship. 4 


VI. Revised FLO Architectures 

After much analysis, two new design requirements 
were identified by the Exploration Program Office, 
which necessitated a change of architectures: global 
lunar access and any-time return capability. 

The lunar exploration architecture must make the 
entire moon available, since the geology is very 
diverse, and since there is a desire to search for ice 
hidden in craters at the lunar poles. In addition, the 
crew must be able to leave the lunar surface to return 
to earth at any time in case of emergency . 14 

Analysis of the three different staging architectures 
resulted in the deletion of the requirement of departure 
from and return to the space station. This was due in 
part to the following reasons: (1) return to a regressing 
station node was too constraining on mission planning, 

(2) free return aborts to station are almost non-existent, 

(3) architectural dependency upon the station was a 
high-risk factor, (4) the station node delays treatment in 
case of medical emergency. 10 

The modified architectures also called for direct 
entry at Earth with a splash-down and recovery. No 
other return options were considered viable at that 
time. 15 The advantages and disadvantages of each 
option are summarized in Table 3. 

VII. Final FLO Proposal 

Unfortunately, funding for FLO was cut only 
months after the contract was awarded. The FLO study 
was concluded in early 1993 with the recommendation 
of the lunar direct architecture. 

Under this proposal, a new heavy lift launch vehi- 
cle capable of placing 225 metric tons in LEO would be 
developed based on the Saturn V. An unmanned crew 
habitat, derived from the space station modules, would 
land autonomously on the lunar surface prior to the 
launch of the piloted vehicle. The crew transfer module, 
resembling the Apollo re-entry module would support 
the crew during the outbound and return legs of the 
flight and double as a lunar lander, performing the lunar 
descent and ascent. The crew would transfer to the 
surface habitat shortly after arrival, and transfer back 
prior to their departure. The module would perform bal- 
listic re-entry and splash down like Apollo. ' 6 

This architecture negated the necessity of develop- 
ing two crew transfer modules and deleted all the phas- 
ing problems involved with staging to and from lunar or 
Earth orbiting nodes. However, this option was the 
most expensive in terms of initial mass in LEO, and 
required the development of a heavy lift launch vehicle. 
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Table 3: Comparison of Revised Lunar Transportation Architectures 


Advantages 

Disadvantages 

Lunar Orbit Rendezvous 

- Minimizes vehicle mass requirements 
by leaving parts in LLO 
• Well suitea for near-equatorial sites 

- Not well suited for off-equatorial sites due to phasing 
constraints and very long or short stay times 

- Any-time return not always available due to earth 
return phase alignment 

- Dual crew cab development 

Lunar Direct 

- Provides global access 

- Any-time abort available 

- Single cab development 

- Eliminates orbital rendezvous 

- Eliminates long-term orbit maintenance 

- Sensitive to crew cab mass 

- Larger launch vehicles required 

- Cargo transported with crew is more limited 

- Smaller crew cab implies greater need for prior 
delivery of a habitat 

High Lunar Staging Point 

- Global access available since plane changes 
less expensive in high orbit 

- Any-time abort available 

- Crew can live out of lander 

- Provides Moderate payload delivery capability 

- Dual crew cab development required 

- Round-trip travel times can be a few days longer 
than LOR or Direct 


VIII. Bevond FLO 

Some figures of merit used in previous studies 
include: (1) Initial Mass in Low Earth Orbit (IMLEO) 
requirements, (2) new technology requirements, (3) 
infrastructure requirements, (4) vehicle development 
requirements, (5) abort options, (6) mission leg travel 
times, (7) surface stay times, (8) station keeping 
requirements / orbital stability (in terms of AV), (9) mis- 
sion planning complexity, and (10) cost in terms of dol- 
lars. 

In the aftermath of the FLO cancellation, studies on 
new and revolutionary lunar mission architectures have 
continued, with emphasis on reducing cost and com- 
plexity. 

Of all the figures of merit, lowering the IMLEO has 
perhaps the most direct effect on cutting cost. In addi- 
tion, reduction in mission complexity, such as rendez- 
vous, docking, and proximity operations, and negation 
of multiple crew modules, has a major cost benefit, 
allowing for the development of a simple crew module. 
The third major cost driver is infrastructure. In general, 
less infrastructure will mean lower program cost. 17 

Lunar Oxygen Utilization 

One revolutionary architecture that could produce 
the greatest cost reduction relies on the production of 


oxidizer from lunar soil for use on the return leg of the 
mission. 

Almost half the mass of lunar regolith is trapped 
oxygen, which can be extracted and refined into liquid 
oxygen. A number of extraction methods have already 
been patented, and one has been successfully tested 
on lunar samples. 

Approximately 85% of the propellent mass for oxy- 
gen/ hydrogen rockets is due to the oxygen; thus, if the 
oxidizer required for the return trip (lunar ascent, 
transearth injection, Earth capture, and deorbit bums) 
could be manufactured on the moon, the IMLEO could 
be drastically reduced. 

This option would remove the difficulties associ- 
ated with LOR operations without incurring the mass 
penalty of the FLO lunar direct architecture, since no 
Earth-return oxidizer would be taken to the lunar sur- 
face. Initial studies show that this architecture could 
require as little as 1/3 the IMLEO of comparable Apollo- 
style LOR or FLO lunar direct architectures. 

With such drastic mass reductions, the develop- 
ment of a heavy lift launch vehicle would not be neces- 
sary. A single shuttle-derived launch vehicle would 
suffice. 

Like the FLO architecture, this so called LUNOX 
architecture would require the emplacement and 
checkout of infrastructure prior to launching the piloted 
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mission. Estimates indicate two shuttle-derived 
launches would be required to deliver the lunar oxygen 
production equipment. 17 

The cost of the first piloted mission was estimated 
to be around $1 9.6 billion, as opposed to the first FLO 
mission at $25 billion. After a half dozen missions, the 
savings compared to the FLO option would be $1 8.5 
billion. The development cost of the robotic surface 
vehicles and oxygen production systems was esti- 
mated to be $3.4 billion. 18 

Future Architectures 

Another architecture which may hold promise 
when a strong human presence is finally in place on 
the moon is the use of a rapid nuclear powered lunar 
shuttle to ferry crew and cargo back and forth between 
Earth and lunar orbit. 

A proposal by NASA’s Lewis Research Center and 
Aerojet's Propulsion Division envisions the use of a 
high Isp nuclear thermal rocket (NTR) augmented by a 
liquid oxygen afterburner to provide a rapid transit shut- 
tle capable of delivering 25 tons of cargo / crew to lunar 
orbit in 24 hours. 

Their scenario envisions workers and cargo being 
transported to LEO via a scramjet, where they would 
be transferred to the rapid transit shuttle module. Once 
in lunar orbit, the module would de-couple and mate 
with a lander, which would take it to the surface. 18 The 
surface infrastructure would presumably rely on lunar 
oxygen to supply the lander taxi with oxidizer for ascent 
and descent. 

IX. Conclusion 

The only thing that can be said of lunar mission 
architectures with any certainty is that they will almost 
certainly evolve as technology and experience 
advance. 

If ice is discovered in sufficient quantities at the 
lunar poles, if the mining of helium 3 becomes realistic, 
or if lunar tourism becomes a reality (as proposed by 
Japan) 18 , cheaper and faster methods of transport will 
certainly be required. 
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ABSTRACT 

A logistics system comprised of two orbital stations for the support of a 500 GW space power satellite scenario in 
a geostationary orbit was investigated in this study. A subsystem mass model, a mass flow model and a life cycle 
cost model were developed. The results regarding logistics cost and burden rates show that the transportation cost 
contributed the most (96%) to the ovarall cost of the scenario. The orbital stations at a geostationary and at a 
lunar orbit contributed 4% to that cost. 


INTRODUCTION 

This study was performed in the time period Oct. 
1987 to June 1992 as part of a Solar Power Satellite 
(SPS) Project at the Aerospace Institute of the 
Technical University of Berlin. The Space Power 
Satellite system is a large number of photovoltaic 
space power plants partially manufactured and 
assembled in geostationary orbit. They deliver 
electrical energy via microwave to rectennas on 
earth for distribution to consumers. The major 
driver for this type of analysis was the assumption, 
that the energy production and supply on earth using 
solar power satellites at a geostationary orbit can 
only be provided at economically competitive 
prices, if the solar satellites and the geo- 
infrastructure are fabricated and implemented using 
lunar resources in addition to the resources provided 
from the earth surface: the use of lunar resources 
reduces the logistics cost up to 67% compared to an 
"all earth" resources scenario. Several studies were 
already performed analyzing, e.g., the impact of 
alternative propulsion types utilized for the scenario, 
or optimizing the design and fleet composition of 
such a scenario involving earth and lunar resources. 
This study aimed to identifiy the basic parameters 
with respect to the type and cost of the logistics 
support associated. 

THE SCENARIO 

In order to perform the analysis a survey of related 
publications was made, relevant studies were 
reviewed and a logistics scenario was established. 
The scenario considered the development, on-orbit 
integration and operations of a 500 GW solar power 
satellite system consisting of 111 5-GW-Satellites in 
a geostationary (GEO) orbit, its supporting GEO- 
and LUNAR-Infrastructure, as well as the dedicated 
logistics orbital stations and resupply launchers and 
vehicles. 


The scenario started with the early deployment and 
operations of an exploration base on the lunar 
surface early in the 21st century. This first lunar 
outpost was to be developed into an exploitation 
Lunar Base with up to 16 facility elements. The 
Lunar Base was to provide mining, production, 
manufacturing and power generation facilities, as 
well as habitation facilities and a Lunar Spaceport, 
where up to 800 people (peak) were to live and 
work. The Lunar base was to export to the 
geostationary infrastructure among others raw and 
construction materials for satellite subsystems and 
structures, microwave converters and liquid lunar 
oxygen as propellant. 

Parallel to the Lunar Base development, there was 
also to be a strong build up phase of the 
geostationary orbital infrastructure (GEO- 
Complex). It was to start with a demonstration 
flight unit of a 10 MW Solar-Power-Satellite in low 
earth orbit (LEO) and a 500 MW prototype in 
geostationary orbit. The further assembly and 
integration of a total of 1 1 1 5-GW-Satellites was to 
be performed in GEO at dedicated orbital assembly 
and maintenance facilities, supported by habitation, 
laboratory and space port facilities. The production 
peak with up to 600 people would arise at about 
year 40 after operations start. The GEO-Complex 
was to consist of up to 10 orbital facilities. The 
transportation and distribution of pressurized and 
unpressurized cargo, propellants, pressurants and 
other supplies and the rotation of crew members 
was to be performed by a local transportation 
company (Geostationary Regional Transportation 
Company, GRET), which served 39 routes in GEO 
with a fleet of vehicles of different types. After the 
peak there were only maintenance and post- 
production activities assumed. 

The earth facilities were to provide the liquid 
hydrogen, propulsion subsystems, as well as 
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electronics, crew supplies and other dedicated 
equipment to the lunar and to the geostationary 
infrastructures. The study logic is shown on figure 
1 . 

THE DEFINITION OF THE LOGISTICS 

SYSTEM 

The Logistics System supported through its 
elements the build up, the operations and the phase 
out of a Solar Power Satellite System by providing 
the transportation, storage and distribution functions 
for the GEO-Complex and for the Lunar Base, 
figure 2. The transportation function was performed 
through dedicated launchers (Heavy Space 
Freighter, HSF) and vehicles (Orbital Transfer 
Vehicle, OTV). The storage and distribution 
function was performed by dedicated orbital stations 
in GEO (Geostationary Space Operations Centre, 
GEO-SOC) and in lunar orbit (LUO-SOC). 

GENERAL ASSUMPTIONS 
The analysis of the implementation and evaluation 
of a cis-lunar logistics system was carried out under 
the following assumptions and ground rules: 
o Transportation of the Lunar Base elements 

and supplies by reusable Heavy Space 
Freighters (HSF) based on the NEPTUNE 
concept design introduced in 121 . 
o Transportation of lunar crew and crew 

related supplies by large capsules (third 
stage of HSF). 

o Establishment of a Lunar Space Operations 

Centre in low lunar orbit as a 
transportation node for maintenance and 
fueling of space vehicles. 

o Use of reusable, chemical propelled orbital 

transfer vehicles with aerobrake return 
from lunar and GEO orbit to earth orbit. 
The third stage of the HSF (cargo OTV) 
return to the earth surface, 
o Utilization of lunar produced LOX for the 

propulsion of the orbital transfer vehicles 
departing from GEO-Complex, lunar orbit 
and surface. All liquid hydrogen is 
produced on earth and distributed to GEO 
and Lunar Base by the HSFs and OTVs. 
o Establishment of a Geostationary Space 

Operations Centre in the GEO-Complex as 
a transportation node for maintenance and 
fueling of space vehicles. 

o Transportation of GEO-Complex elements 

and supplies by reusable HSFs. 
o Transportation of GEO-crew and crew 

supplies by large capsules. 

o Stay time of the crew at GEO facilities and 

on the Lunar Base is 6 months on an 
average. 


o An overall time period of 50 years was 
considered for scheduling and life cycle 
cost estimation. 

THE MODELS 

Three models were developed for the analysis of the 
logistics parameters: 
o the mass analysis model 

o the mass flow model 

o the life cycle cost (LCC) model 

MASS ANALYSIS MODEL 
It served as a tool for the evaluation and analysis of 
the subsystem mass of the Space Operations Centres 
and Orbital Transfer Vehicles. The objective of the 
model was to develop algorithms for the estimation 
of mission and design dependent subsystem mass 
data. These mass data were used for cost evaluation 
purposes in the LCC-Model. 

Space Operations Centre 

The mass breakdown was performed considering 
mission dependent (product tree approach) and 
technical layout (work break down structure 
approach) functions of a Space Operations Centre. 
The technical design of a SOC was derived from the 
second stage of the NEPTUNE heavy launcher 
concept. 


| SOC Net Mass 

(Mg) 

Structure 

91.91 

Propulsion 

0.12 

Propellant Tanks 

26.11 

Attitude Control 

7.37 

Pressur. Habitation 

87.06 

Pressurized Storage 

25.68 

Truss Structure 

14.48 

MicrometeoridProtection 

38.44 

Servicing Facility 

57.66 

Docking/Berthing 

8.89 

Refuelling/Reliquefaction 

8.74 

Robotics 

10.30 

OrbitalSupportEquipment 

7.31 

Spares 

1.22 

Scientific Facilities 

1.74 

Power Generation 

20.48 

Crew Safeguard/Escape 

15.16 

Total Net Mass On-Orbit 

422.67 

Tank Capacity 

1404.75 


Table 1: Reference subsystem mass of a SOC 


The reference layout concept of a SOC is depicted 
on figure 3. The SOC consists of structure, 
habitation modules, storage modules for pressurized 
cargo, facilities for unpressurized cargo storage and 
for docking and berthing, handling and servicing of 
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OTVs. Mass algorithms were developed for each of 
the SOC subsystems established, see table 1 for 
mass breakdown. The SOC initial launch mass 
calculated is approx. 1800 Mg, the net mass 422 
Mg. 

Orbital Transfer Vehicle 

The mass breakdown of the OTVs was derived 
from already established design concepts based on 
chemical propulsion subsystems, i.e. liquid 

oxygen/liquid hydrogen. It was further assumed that 
a few types of vehicles would perform all the 
logistics flights. A fleet of modular cargo/propellant 
vehicles (cargo OTV) and crew vehicles (passenger 
OTV) had to transfer cargo, propellants and 
personnel to GEO and to the Lunar Base 
autonomously. The dimensioning of the vehicles 
was performed for the leg LUO- > GEO, because of 
the traffic density experienced there. The cargo 
OTV has a calculated launch mass of 204 Mg 
(payload 100 Mg) and the crew OTV 83 Mg 
(payload 23 Mg). 

MASS FLOW MODEL 

The mass flow model was developed for the 
simulation of the primary mass flows between the 
infrastructures on the moon, the GEO-Complex and 
the terrestrial surface. 

The overall mass flow is depicted on figure 4. The 
major system variables, which were used as input 
parameters for each scenario year to the mass flow 
model, were: 

o Length of the design and development 
phase (years) 

o Length of the operations phase (years) 
o Length of the phase-out operations (years) 

o Number of working persons in GEO 

o Cargo mass from Lunar Base to GEO 

(Mg) 

o Lunar oxygen mass from Lunar Base to 

GEO (Mg) 

o Terrestrial hydrogen mass from Earth to 
GEO (Mg) 

o Number of working persons on the Lunar 

Base 

o Cargo mass from Earth to Lunar Base 
(Mg) 

Through the processing of the input values the 
following logistics parameters were calculated for 
each year of the cis-lunar scenario: 
o Number of HSF launches and OTV flights 
for each traffic route of the scenario 
o Storage requirements for cargo and 

cryogenic propellant mass on the SOCs 
o Working hour requirements for SOC 

operations in GEO and LUO 


o Logistics cargo and propellant mass 
requirements for SOC operations in GEO 
and LUO 

o Logistics crew resupply mass and OTV 
resupply mass requirements 
o SOC and OTV maintenance working hour 
requirements 

The integration of the SOC activities in the scenario 
is depicted on figure 5. The main variables of the 
primary mass flow of the scenario, i.e. cargo, 
propellants and passengers, are shown. Parallel to 
the primary there is the secondary mass flow for the 
logistics resupply of the SOC in terms of own 
(SOC) resupplies, e.g. maintenance, propellant and 
crew, as well as the resupplies for the OTVs, i.e. 
maintenance and propellant. The services provided 
by each SOC are also shown as an output of the 
station. The services provided are measured in 
working hours and are divided into services for the 
GEO and the Lunar Base cargo, for the OTV 
ferries and services for the own SOC-subsystems. 

Through the simulation of the primary cargo and 
propellant mass flow required for the Solar Power 
Satellite operations, the mass flow of the logistics 
support required, or secondary mass flow, was 
derived. The ratios of primary to secondary logistics 
support parameters were established as logistics 
burden rates for mass and workload for the overall 
logistics system in geostationary and lunar orbit. 
The analysis revealed that the SOC in the lunar 
orbit require the largest amount of propellants for 
the OTV ferries to the GEO. This is explained due 
to the fact that the ferries from lunar orbit to GEO 
must carry all the propellant for the trip to and back 
from GEO. This amount of propellant in LUO 
influences the overall logistics mass burden rate of 
751 (kg/Mg) established, i.e. to every 1000 kg 
cargo mass transported through the logistics system 
751 kg of logistics support mass are required by the 
logistics system itself. 99.8% out of that support 
mass consist of propellant for the OTV 
transportation activities. The corresponding burden 
rate for workload is 0.25, i.e. 25% of the actual 
services (working hours) provided by the two SOCs 
are required for the own subsystem and OTV 
support activities. 


LIFE CYCLE COST MODEL 
The objective of the life cycle cost model was to 
establish cost figures for the logistics support 
provided by the SOCs and the orbital ferries. 
Through the LCC model the overall cost of the cis- 
lunar logistics system utilized was estimated. The 
LCC model is depicted on figure 6. Cost algorithms 
were developed for the calculation of the SOC 
development and production cost using Cost 
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Estimating Relationships (CER) of the following 


type: 

C = a M x 

where 


C = 

cost in manyears 

a = 

system specific parameter 

M = 

Subsystem mass in kg 

x = 

cost specific parameter 


In order to apply the CER algorithms to the 
elements of the SOC, the SOC mass was broken 
down to a lower level, e.g. the mass of the 
pressurized modules was described through 
structure, electrical, electronical and mechanical 
subsystem mass. 

Further assumptions of the LCC model: 
o Commonality factors were established 

considering the parallel development of the 
SOC subsystems, a fact which leads to a 
lower overall development cost, 
o The cost figures were calculated in 

manyears and then transformed into 
$(1990); the value many ear is not 
influenced by inflation. 

o No detailed cost analysis was performed 
for the OTV development and production, 
since this analysis was already done in 
other studies. Instead transportation cost 
figures were derived, and transportation 
prices were established for each leg of the 
traffic model and vehicle type, 
o The design, development and production of 

the SOC lasts 10 years, the implementation 
and build up 4 years. With the operations 
start of the LUO-SOC begins the 
operational phase of the LCC model (50 
years). 

The following major cost groups were established, 
see figure 6: 

o Amortization Cost 

The amortization cost considers the amount 
of SOC development cost, the non- 
recurring production cost and the 
acquisition cost for ground support 
facilities. The amortization cost is 
distributed over the operational phase of 
the scenario. No interest rates were 
charged on the investments because the 
program was assumed to be financed with 
public funds. 

o Indirect Operations Cost 

This cost category considered all the cost 
of the personnel, facilities and services on 
earth, e.g. SOC mission control, 
o Direct Operations Cost 

The direct operations cost includes all cost 
elements of the on-orbit SOC operations 


and OTV transportation flights, e.g. SOC- 
personnel, transportation cost, external 
services of Lunar Base, 
o Recurring Cost 

The recurring cost includes the cost 
elements for the system engineering, the 
follow on production of SOC- 
subassemblies for preventive maintenance, 
the spares and repair parts as well as their 
integration and test. 

The total SOC-development cost for the 1st flight 
unit is calculated to approx. 17,8 billion $(1990) 
and the production cost to 7,8 billion $(1990). The 
overall life cycle cost of the cis-lunar market and 
the life cycle cost of the SOC logistics system were 
also calculated. The overall cis-lunar market 
includes cost figures for the overall payload (cargo) 
transported to the GEO -Complex and the Lunar 
Base in the frame of the SPS scenario, while the life 
cycle cost of the SOC logistics system includes the 
cost elements of the two orbital stations (operations) 
themselves and the supporting flights only. 

OVERALL MARKET 

Since the calculated quantitative cost figures are 
valid for the particular scenario and the assumptions 
applied, it was more interesting to find out 
qualitative figures, i.e. cost allocations in (%) of the 
stations and vehicles in the cis-lunar market. 
Provided that the average annual cost of operations 
in the overall cis-lunar market was calculated to 
approx. 80 billion $(1990), the transportation cost 
represents the largest amount with 96%. The 
distribution of the calculated cost percentages over 
the life cycle of the market and the stations is 
depicted on figure 7. The specific cost for cargo 
mass transported and distributed through the stations 
in LUO and GEO was estimated to approx. 760 
$(1990) per kg mass. 75% of that cost fall into 
GEO-SOC due to the high mass flow rates and the 
associated cost, and 25% into the LUO-SOC. 

LOGISTICS SYSTEM 

The specific logistics cost at the two space stations 
was calculated to 27 $(1990)/kg, i.e. 27 $ for each 
kg cargo mass transported through the logistics 
system of the LUO and GEO stations, and 
represents 3,6% of the overall life cycle cost. The 
major contributor to the LCC of the orbiting 
stations is the recurring cost (35,4%) of the stations 
hardware. The transportation cost contributes 9,6% 
to the overall station cost, see figure 8. 

The cost for personnel on the SOCs was calculated 
for both LUO and GEO, pending on the workload, 
the traffic density of the stations and the cargo mass 
flow. The personnel cost consisted of cost elements 
for crew transportation, crew training, on-orbit life 
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support and salary. Specific cost figures were also 
derived for on-orbit working hours. As an average 
value 5000 $(1990)/hour was calculated for the 
GEO-SOC. The specific cost of a wor king hour at 
the LUO-SOC was in the range of 30% of that 
value. The on-orbit stay time for the crew members 
was rated accordingly to approx. 12,5 milli on 
$(1990) per person per year. The cost of the LUO- 
SOC was approx. 32% lower than that of the 
GEO. 

Specific cost elements for the inco ming and 
departing ferries, as space port fees, were also 
derived by applying the cost figure 27 $/kg payload 
mass and station specific factors. This amount was 
distributed to 93% to the LUO station and 7% to the 
GEO station. This was due to the fact that the 
ferries were transferring full loaded cargo ma« 
from LUO to GEO and returning back empty (mass 
flow direction). Passenger ferries were carrying in 
both directions crew members and showed rather 
balanced figures; the fees for passenger ferries were 
distributed to 54% to the GEO station and to 46% 
to the LUO station. 

An impression of potential clusters of space 
operation centres in GEO and LUO is given on 
figure 9. The analysis indicated a higher demand on 
propellant storage capabilities in the lunar and a 
higher demand for space ferry operations in the 
geostationary orbit. 

SUMMARY 

The logistics analysis of the operations of a l unar 
based solar power satellite scenario revealed that the 
transportation cost is the major contributor (96%) to 
the overall cost of the cis-lunar market. Logistics 
burden rate evaluations indicate that 0.75 kg of 
logistics mass for each kg of cargo mass and 0.25 
maintenance hours for each working hour for cargo 
servicing were required. The average life cycle cost 
of a logistics system comprised of two orbital 
stations in geostationary and lunar orbit includi ng 
the dedicated resupply flights was approx. 2.7 
billion $(1990) per year. 

The logistics system of the two stations analyzed in 
this paper is only a part of the overall system in 
GEO and LUO. Since the real demand on logistics 
support and services depend on the cis-lunar 
market, the optimization of the whole system, i.e. 
orbital stations plus launchers plus orbital ferries, 
may lead to a reallocation of functions and services 
envisaged and thus influence the cost figures 
presented. Logistics cost elements and burden rates 
contribute the most to a transparent evaluation and 
economic trade off analyses of alternative scenarios 
and their supporting infrastructures. 


US! QF A CRONYMS AND ABBREVIATIONS 

GEO Geostationary Orbit 

GRET Geostationary Regional Transportation 
Company 

HSF Heavy Space Freighter 
LCC Life Cycle Cost 

LOX Liquid Oxygen 

LUO Lunar Orbit 

OTV Orbital Transfer Vehicle 

SOC Space Operations Centre 
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Study 

Objectives 



Figure 1: Study logic 



SOC: Space Operations Centre 
OTV: Orbital Transfer Vehicle 
HSF: Heavy Space Freighter 

Figure 2: Cis-lunar scenario 
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Figure 3: Reference SOC configuration 
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SOC mass flow categories and output 
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Figure 5: Mass flow model 



Figure 6: 


Life cycle cost model 
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Transportation and SOC Cost in the Cis-Lunar Market 



Figure 7. Allocation of cost in the overall cis-lunar market 
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Figure 8:Allocation of stations cost 
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Connecting Structure 



Geostationary Orbit 



Lunar Orbit 


Figure 9: Example of SOC-clusters in GEO and LUO 
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Introduction 

The U.S. space launch program no longer 
dominates the world and is now playing "catch-up" with 
the world’s first commercial launch company, 
Arianespace. A healthy U.S. commercial launch 
program is essential and will assure continued low-cost 
military access to space. The effort to regain the lead 
in commercial space launch market has been hindered 
by declining Department of Defense budgets. President 
Clinton’s space policy prohibits expensive new launch 
vehicles and limits the Department of Defense to low 
cost upgrades of existing launch vehicles. The U.S. 
government created the space sector and must ensure a 
smooth and effective split from the emerging 
commercial space program in order to regain world 
dominance. Until U.S. government and commercial 
ties are severed, the Department of Defense must 
consider commercial space launch interests when 
making military decisions. 

Ariane provides an excellent "bench mark" for 
the U.S. to base future launch vehicle upgrades. 
Ariane advantages were identified and low-cost 
recommendations have been made. If the U.S. sets the 
target of first equaling and then surpassing Ariane by 
incorporating these recommendations, then the U.S. 
could once again dominate the world commercial launch 
market and ensure low cost military access to space. 

Does the U.S. have a commercial space launch 
problem? 

The U.S. space industry lost its lead in 
launching commercial satellites several years ago, and 
is falling further behind every day. The United States, 
for seventeen years from 1965 to 1981, launched every 
commercial satellite. The world’s first and only 
commercial space launch company, Arianespace, is 
responsible for taking the lead away from the United 
States. Arianespace now dominates the commercial 


launch market by launching 65% of the world’s 
commercial satellites. 1 The entry of China, Japan, and 
Russia further reduced U.S. launches to less than 26% 
(Figure 1). An estimated $1 billion each year is lost to 
outside space launch competition. The demise of the 
U.S. commercial launch business will continue at an 
ever increasing rate with the emergence of the Chinese, 
Japanese, and Russian commercial space launch 
programs and the debut of the Ariane 5. The future for 
U.S. commercial space launch business looks grim 
unless immediate corrective action is taken. 



FIGURE 1. COMMERCIAL SATELLITE LAUNCH 
VEHICLES, 1988-1992, 74 SATELLITES 


Why should anyone care about the U.S. commercial 
launch program? 

Why should the American public care whether 
or not the U.S. commercial space launch business is 
lost to foreign competition? There are four reasons 
why Americans should be concerned about the U.S. 
commercial space launch future. 

The first and probably the most important 
reason is the economic future of the United States. The 
standard of living for Americans depends on the 
economic health generated by successful worldwide 
competition. The rules of worldwide trade will be 
written by those who dominate the market and everyone 
else will have no choice but to play by those rules. 2 
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The second reason is the concern for excessive 
expenditures of tax dollars. Military space programs 
consume a large amount of tax dollars and every effort 
should be taken to keep those costs down. Competitive 
commercial space launch businesses can help keep 
military expenditures down for those companies that 
take on both commercial and military contracts. 

The third reason is national security by 
providing continued access to space for the U.S. 
military. A healthy U.S. commercial launch program 
will assure continued low cost military access to space 
because of shared technology between the government 
and commercial sectors. 

The fourth reason is national pride, which has 
driven many previous space activities. President 
Kennedy was the best example of one man who pulled 
the nation together for the race to the moon because he 
believed that the United States could not be second in 
the eyes of the world, because second was last. 3 The 
American people should be concerned about the future 
of the U.S. commercial space launch program. 

What has the government done to help the commercial 
space launch program? 

Each of the mainstay launch vehicle 
manufacturers (Atlas, Delta, and Titan) have been 
products of a nineteen sixties government sponsored 
space race. The government needs to support the 
emergence of a commercial launch program from the 
womb of the original government dominated space 
program. The separation of government and 
commercial programs has been a slow and difficult 
process that is far from complete. Government, 
military, and commercial launch programs have been 
interwoven into a maze of restrictive, overlapping, 
inconsistent, and politically driven U.S. space policies. 

The U.S. government has conducted numerous 
surveys and organized many committees to research the 
space program problem and provide recommendations 
to Congress. During the last administration. The Vice 
President’s Space Advisory Board Report, November 
1992, and the Final Report to the President on the U.S. 
Space Program, January 1993, both recommended a 
new family of launch vehicles and centralized 
management. The U.S. fiscal crisis worsened with the 
end of the Cold War and military budgets became easy 
prey for the fiscal feeding frenzy of the last thirty 
years. 4 A number of President Clinton’s initiatives are 
under way to again study the problem and recommend 
a less expensive plan of action. 5 A recently released 


draft of the Clinton’s launch policy recommends that 
the military be limited to improving existing launch 
vehicles for military payloads. 6 The U.S. military has 
been limited to low cost incremental changes to the 
existing older Atlas, Delta, and Titan launch vehicles 
for improving both the military and commercial space 
launch programs. 

Why does the government need to rescue U.S. 
commercial launch companies? 

U.S. commercial space launch programs need 
to be freed from burdensome policies that prohibit rapid 
and consistent decisions that are required of competitive 
programs. The following example shows how a simple 
government decision to modify a launch pad destroyed 
commercial opportunities for Martin Marietta. An 
earlier government decision to convert a Titan 3 to a 
Titan 4 launch pad left only one Titan 3 launch pad 
capable of launching commercial satellites. True, there 
was a second launch pad on the west coast, but it has 
never been capable of launching commercial satellites 
into their required geostationary orbits. Martin 
Marietta’s, commercial division, launched just three 
satellites before the only remaining launch pad was shut 
down for Titan 4 modifications. The launch pad was 
out of commission for two years and all commercial 
Titan 3 launches were terminated while customers 
sought launches elsewhere. For the benefit of the 
nation and the future of the U.S. commercial space 
launch programs, the government has an obligation to 
ensure a smooth and effective split between government 
and commercial space launch programs. 

Why has Ariane been able to capture the commercial 
launch market? 

Arianespace recognized the potential of 
commercial space transport and built a line of launch 
vehicles tailored specifically to the needs of the world’s 
commercial satellite organizations. 7 The Ariane family 
of space launch vehicles is specifically designed to 
deliver payloads directly to geostationary transfer orbit 
because commercial payloads are geostationary 
communications and observation satellites. They offer 
sixteen different launch configurations that cover a 
broad range of payload sizes at consistently low prices. 
Ariane also offers multiple launch capability that allows 
all sizes of satellites to be matched to one of the sixteen 
different launch configurations to achieve a consistently 
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high maximum payload. The Kourou, French Guiana 
launch facility is located near the equator, which 
provides a 15% energy savings over U.S. launched 
spacecraft bound for geostationary orbit. 8 The large 
family of Ariane space launch vehicles offers a number 
of significant advantages that help explain why 
Arianespace has captured the commercial launch 
market. 


What about other foreign launch competition? 

China, Japan, and Russia have launch vehicles 
capable of providing tough competition with the United 
States. Launch competition from these three countries 
has been temporarily held at bay because of satellite 
export restrictions from the United States. U.S. 
companies still build most of the world’s commercial 
satellites even though foreign competition is thriving. 
Sixty nine percent of all the world’s commercial 
communications satellites scheduled for delivery from 
1992 to 1997 will be built by a U.S. prime contractor. 9 
The U.S. government has placed a number of export 
bans on U.S. built commercial satellites to foreign 
countries in order to protect the U.S. commercial 
launch business. 

The major reason for export bans has been the 
unfair pricing advantage of government subsidized 
launches. Export licenses of U.S. manufactured 
satellites have been withdrawn from China for 
accusations of price dumping, internal human rights 
disturbances, and missile proliferation. 10 Concerns 
over unfair Chinese pricing prompted the U.S. 
government in 1988 to limit satellite exports to nine by 
the year 1994, and all costs would be compatible with 
the international launch market. 11 The Russians have 
also been denied export licenses, in 1989, for U.S. 
manufactured satellites for reasons of illegal technology 
transfer and price dumping. President Bush reversed 
the decision in 1992, and approved one launch of a 
U.S. built satellite. 12 A more recent U.S and Russian 
agreement was reached in 1993 that allowed eight 
Russian Proton geostationary commercial satellite 
launches through the year 2000. 13 Both the Chinese 
and Russians have obtained commercial satellite 
contracts that have been outside the jurisdiction of the 
United States, which explains their gradual growth of 
the commercial satellite market. 

The Japanese, on the other hand, have not 
offered competitive prices to foreign commercial 
satellite customers. The earlier N1 and HI launch 
vehicles were hybrid American and Japanese designs 


that were never price competitive even though they 
were very reliable. The new all Japanese H2 is one of 
the world’s most efficient heavy launch vehicles, but 
the high development costs have temporarily prohibited 
competitive launch pricing. 14 The Japanese intend to 
reduce the costs of their H2 to make them competitive 
with the Anane, by simplifying production with 
increased automation and reducing material costs by 
using cheaper materials and simpler structures. 15 
Another tremendous setback for the Japanese H2 is the 
internal environmental restriction of only four launches 
per year to protect the nearby fishing industries from 
unnecessary loss of fish. 16 The Japanese H2 will 
become a competitive launcher of commercial satellites 
only when and if they can bring their prices down. 

How will the U.S. compete with the emerging foreign 
launch competition? 

Americans do not seem to care that they are 
falling behind the most advanced part of the industrial 
world. Their most comfortable hypothesis is the belief 
they do not need an economic game plan. 17 For 
nearly a decade, Ariane has been consistently launching 
more commercial satellites than the all of the U.S. 
launch vehicles combined. Many years have passed 
without a concrete plan to maintain the lead or at the 
least, keep up with foreign competition, especially 
Arianespace. Now, the U.S. has found that playing 
"catch-up" is considerably more difficult than keeping 
up with foreign launch competition. Lester Thurow, 
author of Head to Head , provides the steps required to 
catch up with the competition. 

A country that wants to win 
starts by closely studying the 
competition. The purpose is not 
emulation but what the business world 
calls "bench marking." Find those in 
the world that are best at each aspect 
of economic performance. Measure 
your performance against theirs. 
Understand why they are better. Set 
yourself the target of first equaling, 
and then surpassing, their 
performance. 18 

Arianespace was selected as the "bench mark" 
for this study because of their significant performance 
and outstanding success in capturing a majority of the 
world’s commercial geostationary launch market. Their 
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performance was then compared to U.S. launch 
vehicles in four areas that were identified as being 
important: (1) payload characteristics, (2) costs for 
delivery, (3) launch vehicle selection process, and (4) 
technology. Space launch program comparisons 
uncovered a number of differences that gave Anane a 
significant advantage and those differences evolved into 
"catch-up" and "get ahead" recommendations. 

The first measure of performance: payload 

characteristics 

Payload characteristics were selected as the 
first performance standard because of their importance 
to the launch vehicle. The sole purpose of the launch 
vehicle is to deliver a payload to a particular stellar 
location. The world’s space launch vehicles have 
placed 392 communications and observation satellites 
into 22,300 mile geostationary orbit from 1965 through 
1992. A little more than 50% , 198, of those have been 
commercial satellites that have cost about $12 billion, 
1993 U.S. dollars, for delivery to orbit. Because the 
U.S. had such a strong lead in the beginning, Ariane 
still has only launched 66 compared to 117 U.S. 
launched commercial satellites (Figure 2). 



FIGURE 2. ARIANE VS. US LAUNCHED 
COMMERCIAL SATELLITES 


Arianespace’s goal, from the very beginning, 
has been to launch half of the world’s commercial 
satellites. 19 Their goal will become a reality within 
the next few years. 

An average of fifteen commercial satellites per 
year are now being launched and that number will 
steadily increase if past trends continue. 20 Average 
payload weights have also steadily increased (Figure 3) 
from the first 39 kg (86 lb) Intelsat 1 to an average of 
nearly 1200 kg (2700 lb). 21 Payload quantities and 
size will continue to increase in the foreseeable future. 


Ariane closely monitors increasing payload sizes and 
ensures that their vehicle upgrades keep up with 
commercial needs. U.S. launch vehicles, on the other 
hand, are still being tailor made to specific military 
payloads. 



FIGURE 3. COMMERCIAL SATELLITE WEIGHT, 
1965-1992 


The second measure of performance: launch costs 

Commercial satellites typically are designed to 
go to higher, more expensive, geostationary orbits 
where they travel in synchronization with the Earth’s 
rotation and appear to be stationary. Space launch 
vehicles take only the payload and a booster motor to 
an orbit called a geostationary transfer orbit (GTO). A 
GTO is a highly elliptical orbit used to take the payload 
out to 22,300 miles where the satellite booster motor 
fires to move the satellite into its final circular 
geostationary orbit (GEO). Launch costs were 
estimated using payload costs per pound to reach a 
geostationary transfer orbit. The overall cost for a 
flight was divided by the payload weight to obtain the 
cost per pound rate. The U.S. Atlas, Delta, and Titan 
launch costs were compared to the "bench marked" 
Ariane for all commercial flights from 1988 to 1992. 

The Atlas 1/2, Delta 2, and the Titan 3 cost 
per pound rates were all unbelievably less than Ariane 
4 by as much as 25 % (Figure 4). How can this be true 
after hearing all the accusations of U.S. launch vehicles 
being too costly? The lowest rates were commonly 
achieved by U.S. launch vehicles carrying military 
satellites. Military satellites typically used 100% of the 
payload capacity for the tailor-made U.S. launch 
vehicles. 22 Commercial satellites have been poor 
matches to U.S. launch vehicles and averaged less than 
80% of the rated payload capacity. 23 Ariane payloads, 
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FIGURE 4. ARIANE VS. US LAUNCH VEHICLE COSTS 


on the other hand, averaged more than 90 % of the rated 
maximum payload. 24 The average launch costs for 
commercial satellites aboard U.S. launch vehicles was 
slightly greater than $17,500 per pound, whereas, 
Ariane dual payload launch costs averaged $ 15,600 with 
single payload launches averaging only $12,200. 25 

Ariane multiple payload configurations gives 
Ariane an excellent tool for keeping costs down for 
different sized payloads. Two different sized payloads, 
hat may cost considerably more on any other vehicle, 
can be matched to obtain a near full payload on an 
Anane launch vehicle. Ariane’s multiple payload 
capability and 16 different launch configurations 
provides the significant advantage of being able to 
launch almost any size satellite for a reasonable rate by 
maximizing the launch vehicle takeoff weight limits. 

The Anane launch site in Kourou, French 
Guiana, offers a 15 % advantage over launches from the 
U.S. because Kourou is near the equator. The Ariane 
launch advantage should be factored out when 
comparing Ariane to U.S. launch vehicles. With a full 
load, rates as low as $7,500 for Atlas 2A, $9,300 for 
Delta II 7925, and $8,800 for Titan 3 could be obtained 
if the Ariane launch advantage is factored out, 
compared to Anane ’s $12,000 per pound average for its 
sixteen configurations. 


The thir d measure of performance: launch vehicle 
selection 

Launch vehicle selections were reviewed for all 
of the commercial launches from 1988 to 1992, in order 
to identify basic selection criteria used by the satellite 
owners. Launch vehicle decisions made by satellite 


organizations were found to be primarily dependent on 
cost per pound rates offered by launch vehicle 
manufacturers. A number of basic pass-fail criteria was 
first considered before the decision was reduced down 
to one of cost. Reliability, warranty, accuracy of 
placement, stress on the payload, export restrictions, 
and launcher availability were some of the key pass-fail 
items that sometimes narrow down the choice of launch 
vehicles. A few exceptions to the lowest cost per 
pound selection were noted by some organizations and 
countries that had loyalties to particular manufacturers. 
China, France, Russia, and the U.S military have 
always used specific launch vehicle manufacturers 
within their own countries. Even a few international 
communications companies with worldwide ownership 
seemed to have launch vehicle manufacturer preferences 
that related to the ownership percentages. But, without 
a doubt, most launch vehicle selection decisions were 
based on cost per pound rates to deliver the payload to 
geostationary transfer orbit. 


The fourth measure of performance: launch vehicle 
technology 

The review of launch vehicle technology was 
divided into three areas: (1) engine efficiency, (2) 
payload-to-takeoff weight ratios, and (3) reliability. 
Engine performance criteria was identified as engine 
efficiency rated in specific impulse (Isp), which is a 
ratio of the amount of fuel consumed to maintain a 
particular engine thrust. The payload-to-takeoff weight 
ratio was identified as a performance characteristic to 
measure how much rocket mass was expended to 
deliver a payload to a geostationary transfer orbit. 
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Reliability is another performance characteristic that 
estimates the odds of the payload reaching the desired 
orbit. 

Liquid engine performance ratings have not 
increased significantly in the last thirty years and all of 
the world’s launch vehicle manufacturers seem to have 
the latest liquid engine technology. The 1960’s Russian 
Proton engine is still the most efficient kerosene liquid 
engine and the 1970’s Shuttle liquid hydrogen and 
oxygen main engine is the world’s most efficient 
engine. 26 Solid propellent motor performance has 
been slowly improving and the Titan 4, SRMU solid 
propellent strap-on booster, is the world’s most 
efficient. Ariane launch vehicles use conservatively 
rated engines that are less efficient than any of the U.S. 
engines. There seems to be little advantage in the type 
of engine used for launch vehicles because the cost-to- 
performance tradeoffs are not significantly different. 
The lower performance solid boosters are less 
expensive and the higher performance liquid engines are 
more expensive. 

The payload-to-takeoff weight performance 
ratios were found to be a relative indicator of payload 
launch costs. Most geostationary transfer orbit launch 
vehicles expend 99 % of the takeoff weight in reaching 
orbit (Figure 5). Generally, the lowest payload cost per 
pound launch vehicles were near the high end of the 
payload-to-takeoff weight ratios and the more expensive 
ones had low ratios. Launch vehicle takeoff weight 
brings out the seriousness of weight reduction programs 
because cost efficiencies must drive the performance 
ratings and not the other way around. The Atlas 
has the highest payload-to-takeoff weight ratio, 1.6%, 
of all the world’s launch vehicles. 27 The Titan 4 with 
the SRMU solid strap-on boosters and the Centaur 
upper stage has a higher ratio than all of the Ariane 
configurations. The Delta is in the lower third, below 
Ariane. 

Strange as it sounds, launch vehicle success 
rates had little influence on the vehicle selection 
process. Launch vehicle customers seemed to be very 
tolerant of companies that were experiencing temporary 
setbacks from failures. Even when launch companies 
were suffering from consecutive failures, the customers 
for the upcoming flights never withdrew their payloads 
from the launch manifest for a number of reasons: (1) 
a rescheduled flight on another launch vehicle would 
have delayed the launch for about two years, (2) 
contract penalties would have been costly, and (3) there 
was a high probability that the launch vehicle problem 
would be corrected before the next flight. For 
customers that unfortunately lost their payload to a 


launch vehicle failure, they typically collected a 
percentage of the satellite construction costs from flight 
insurance and were offered another free launch as part 
of the warranty. 

The plan to regain U.S. commercial launch dominance 

Ariane has only three technical advantages over 
the U.S. launch vehicle companies: (1) 16 different 
launch vehicle configurations, (2) multiple payload 
capability, and (3) a 15% energy advantage of 
launching from Kourou, which is near the equator. If 
these three advantages are factored out, then Atlas 1/2, 
Delta 2, and Titan 3 would all be significantly more 
cost effective than Ariane. President Clinton’s basic 
space launch policy prohibiting large expenditures on 
new spacecraft and limiting the military to low-cost 
upgrades to existing launch vehicles provides enough 
funding to solve the U.S. space launch problem, but 
only if the funding is used to implement multiple launch 
capability, additional configurations, and a new launch 
facility near the equator. His suggested upgrades 
include such things as replacing hydraulics with 
electromechanical systems, using lighter-weight 

materials, and updating avionics and software. 28 
Clinton’s launch vehicle upgrades may lower the costs 
even more for military payloads, but they do not 
address any of the issues that would help the U.S. 
commercial launch organizations reclaim the 

commercial launch market. The military is only 
watching out for themselves by lowering the costs for 
their military payloads. They have not yet realized the 
importance of a healthy U.S. commercial launch 
program that will, in the long term, provide continued 
low cost access to space. The U.S. could reclaim their 
once-held lead in launching commercial satellites if 
upgrades to the existing launch vehicles included the 
multiple launch capability, additional configurations, 
and a new launch facility near the equator. 

Recommendation 1 

Fund a multiple payload option upgrade for the 
existing Atlas 1, 2, 2A, 2A Block 1, 2AS and 2AS 
Block 1 configurations in order to compete with Ariane 
4 multiple launch capability. Also, fund a multiple 
payload option, four or more satellites, upgrade for the 
existing Titan 4, SRMU and Centaur configuration in 
order to compete with the Ariane 5 multiple launch 
capability. 
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FIGURE 5. PAYLOAD-TO-TAKEOFF WEIGHT PERCENTAGES 


The most important difference between Ariane 
and U.S. launch vehicles is Ariane’s ability to launch 
multiple payloads. This one advantage is the key to 
understanding why Ariane now dominates the 
commercial launch market. U.S. launch vehicles had 
full load rates as low as $7,500 per pound for the Atlas 
2A, $9,300 for the Delta II 7925, and $8,800 for Titan 
3, but their average costs for commercial satellites were 
an incredibly high $17,500 per pound. Most of their 
launch vehicles flew with half empty cargo holds 
because they were not able to match payloads to 
optimize the payload capacities. 

The military Titan 3 has the same payload 
capacity as the Ariane 4 and has been launching dual 
payloads for the military for over twenty years. The 
Titan 3 upgrades never kept up with increasing 
commercial payload sizes at economically competitive 
prices. The Titan 3 was designed to be both a low- 
Earth and a GTO launch vehicle with design efficiency 
emphasis on low-Earth orbit injection. Because of the 
low-Earth design emphasis, the second stage must go to 
low-Earth orbit before sending the last stage on to a 
geostationary transfer orbit, which makes the Titan 3 
less efficient at sending payloads to geostationary orbit. 
The Atlas, on the other hand, is a perfect candidate for 
a multiple payload configuration upgrade. The Atlas is 
smaller than the Ariane 4, but could lure plenty of 
smaller payloads from Ariane. Ariane would then have 
a difficult time matching the larger payloads for 
multiple payload Ariane 4 and 5 configurations. Going 
after the smaller payloads is one way to regain part of 


the commercial launch market. 

The Anane 5, multiple launch configuration, 
will be capable of launching three satellites, which will 
provide a tremendous opportunity for Arianespace to 
match an even wider range of payloads to fill the 
spacecraft to its takeoff limit. Costs will be unbeatable 
unless the U.S. tops that with a Titan 4, SRMU and 
Centaur configuration, capable of launching four or 
more satellites to a geostationary transfer orbit. The 
Titan 4 also needs to be modified for a more efficient 
flight trajectory that would go directly to a 
geostationary transfer orbit instead of stopping at low- 
Earth orbit. 


Recommendation 2 

Fund economical launch vehicle upgrades to 
increase the number of launch configurations that widen 
the payload window while keeping the cost per pound 
rates low. 

The second most significant technical 
advantage Ariane has is their ability to accommodate a 
wide variation of payload weights with their 16 
different economical launch configurations. Any one of 
these configurations is available for use, whereas, U.S. 
launch companies are forced to phase out older 
configurations because they are no longer needed for 
military payloads. Every effort should be made to 
increase the number of usable launch configurations for 
Atlas, Delta, and Titan launch companies. Many 
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military payloads. Every effort should be made to 
increase the number of usable launch configurations for 
Atlas, Delta, and Titan launch companies. Many 
different launch configurations are necessary to provide 
low cost rates over a wider range of payload weight. 

Recommendation 3 

The Department of Defense and commercial 
launch companies should build a launch facility near the 
equator to obtain a 15 % savings in geostationary launch 
costs. 

The third most significant advantage achieved 
by Ariane is their ability to launch from near the 
equator, which provides them with an immediate energy 
savings over comparable U.S. launch vehicles launched 
from Florida. A new U.S. launch facility would 
provide an immediate 15 % cost savings for all flights 
to geostationary orbit. Ariane is not the only 
organization that will be taking advantage of the 
equatorial advantages, representatives from the Space 
Transportation Systems, Ltd., of Australia and four 
Russian enterprises have signed an exclusive 20 year 
$750 million contract for commercial equatorial launch 
services from Papua, New Guinea. The Russians claim 
the Proton can lift an additional 40% payload from the 
equator over their own northern Baikonur Cosmodrome 
launch facility. 29 The U.S. already owns two islands 
near the equator that could be used for a new U.S. 
launch facility. U.S. Baker Island and Howland Island, 
south of the Hawaiian Islands, are located closer to the 
equator than either New Guinea or Kourou. The initial 
investment would take many years to recover, but the 
advantages may make the difference for U.S. space 
launch survival. 


Recommendation 4 

Reduce the size and weight of future military 
satellites to be consistent with the size and weight of 
commercial satellites to benefit both the U.S. military 
and commercial launch sectors by providing common 
designs. 

Military payloads have been designed to 
specifically carry out the intended mission regardless of 
the size and weight, which means that military payloads 
were seldom the same size and weight as commercial 
payloads. The Titan 3 was designed over thirty years 
ago and was capable of carrying military payloads that 
were many times the size of the largest commercial 


payload. The Titan 4 is also a very heavy lifter for its 
day and is capable of carrying more than twice the 
weight of today’s largest commercial payloads. The 
size of military satellites needs to be scaled back to the 
same size of commercial satellites so that common 
spacecraft can be used for launching both military and 
commercial payloads. 

Recommendation 5 

Continue and encourage the split of military 
and civilian space launch programs in order to provide 
commercial sectors enough freedom to make 
competitive choices and react quickly enough to catch 
commercial opportunities. 

Add a civilian contingent to the U.S. Space Command 
management structure and the Pentagon who would 
have the power and authority to influence decisions that 
concern commercial launch issues. 

After "bench marking" Ariane and studying 
their performance strengths, a number of options have 
been uncovered that can be used to catch up and even 
surpass the success of Ariane. The survival of the U.S. 
commercial launch programs is in the hands of the 
Department of Defense until the commercial programs 
can become autonomous. Ground operations, launch 
facilities, and space policies are largely government 
controlled even though each of the three major launch 
companies (Atlas, Delta, and Titan) have their own 
commercial divisions and manufacture their own 
spacecraft. Too many military decisions are being 
made that have been detrimental to the future of the 
U.S. commercial launch business. Until commercial 
launch vehicle companies can break away from military 
entanglements, they will be unable to make the required 
competitive choices to ensure a future in the world’s 
commercial launch market. 


Conclusion 

The U.S. commercial space launch program no 
longer dominates the world and is now playing "catch- 
up" with the world’s first commercial launch company, 
Arianespace. The U.S. government created the space 
sector and must ensure a smooth and effective split 
from the emerging commercial space program in order 
to regain world dominance. Ariane, who is beginning 
to create their own world trade rules, is no longer 
tolerating subsidized launch vehicles. Until U.S. 
government and commercial ties are severed, the 
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Department of Defense must consider commercial space 
launch interests when making decisions. 

Ariane has provided an excellent "bench mark" 
for the U.S. to base future launch vehicle upgrades. 
Ariane advantages were identified and low-cost 
recommendations have been made. If the U.S. sets 
the target of first equaling and then surpassing Ariane 
by incorporating these recommendations, then the U.S. 
could once again dominate the world commercial launch 
market. 
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ABSTRACT: 

Our satellite systems are mega-buck items. In 
today’s cost conscious world, we need to reduce 
the overall costs of satellites if our space 
program is to survive. One way to accomplish 
this would be through on-orbit maintenance of 
parts on the orbiting craft. In order to 
accomplish maintenance at a low cost I advance 
the hypothesis of having parts and pieces 
(spares) waiting. Waiting in the sense of having 
something when you need it, or just-in-time. 
The JIT concept can actually be applied to space 
processes. Its definition has to be changed just 
enough to encompass the needs of space. Our 
space engineers tell us which parts and pieces 
the satellite systems might be needing once in 


orbit. These items are stored in space for the 
time of need and can be ready when they are 
needed - or Space Based JIT. When a system 
has a problem, the repair facility is near by and 
through human or robotics intervention, it can 
be brought back into service. Through a JIT 
process, overall system costs could be reduced as 
standardization of parts is built into satellite 
systems to facilitate reduced numbers of parts 
being stored. Launch costs will be contained as 
fewer spare pieces need to be included in the 
launch vehicle and the space program will 
continue to thrive even in this era of reduced 
budgets. The concept of using an orbiting parts 
servicer and human or robotics 
maintenance/repair capabilities would extend 
satellite life-cycle and reduce system 
replacement launches. Reductions of this nature 
throughout the satellite program result in cost 
savings. 


What we did in the past, we do not want to do in the future. 
General Charles Homer 18 Sep 92 


DISCUSSION: 

The simple fact of distance has never been a real 
factor in material distribution-as long as you 
were still on earth. Getting a specific part when 
needed or within set time parameters became 
easier once the Just-In-Time (JIT) distribution 
concept was recognized and implemented. The 
JIT process is a material distribution concept 
plan where external suppliers deliver raw 
materials to the manufacturing facility just at the 
time the customer is ready to use those 
materials. As an internal continuation of the 


process, one department is pushing the product 
down the line just as the next department is 
ready to start using the product for their internal 
process. The JIT process has been proven to 
reduce costs when used properly. Storage costs 
are reduced, production time and costs are 
minimized and the overall manufacturing 
budgets are less. The work center is provided 
with the proper quantity of materials and 
components needed to do a given job at the 
exact time the materials are needed-or just in 
time. 
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Again, this concept is great, while you are on 
earth. One of the very first lessons learned from 
space travel had to do with planning what to 
bring along to assure you had what you needed 
when you needed it, or Space-Based JIT. It 
simply wasn’t as easy in zero gravity to “space 
walk” over to the store for a missing part or that 
extra screw. We’ve learned our lessons well. 
Spares planning has become a very important 
aspect of every space mission: plan ahead for 
every eventuality, expect the failure and be ready 
for it. The concept of JIT needs to be expanded 
into the space arena. JIT needs to go beyond 
simple material distribution and enter a new, 
more complex dimension in space. The JIT 
distribution concept can work in space. 

The integrated logistics support (ILS) elements 
(Figure 1) are the cornerstone for every project 
from conception to completion and concept of 
the replacement project. They cover 10 very 
important aspects of management functions 
through a disciplined, unified and iterative 
approach. While many logistics text books print 
the ILS elements in the order as shown in the 
referenced figure, I feel the last item on the list, 
Design Interface, is by far the most important of 
the 10. If not the first on the list, it should be 
the first logistical element in place following 
recognition of need. It needs to be the one 
element around which all the others revolve. 


1. Maintenance Planning 

2. Manpower and Personnel 

3. Supply Support 

4. Support Equipment 

5. Technical Data 

6. Training and Training Support 

7. Computer Resources Support 

8. Facilities 

9. Packaging, Handling, Storage and 
Transportation 

10. Design Interface 


FIGURE 1. Integrated Logistics Support 
Elements 


Design Interface considers and accepts or rejects 
aspects of initial conception and design. It 
includes necessary activities and training 


required for production. The design interface 
process integrates parts requirements into the 
overall picture throughout the life cycle. Design 
interface also addresses disposal or removal. 
Design interface is total support; total support of 
a system/project/idea covered through 
application of and processing through this one 
element. Supportability planning and related 
design considerations must be included in the 
requirements definition process and thoroughly 
evaluated during concept development to ensure 
options can be reasonably implemented in the 
operational system. 1 Design Interface will 
support our Space Based JIT concept 

The space program we envision today for our 
future will most likely be quite different from 
the one we actually put into place. Budget 
constraints and even public opinion will drive 
and change many of our plans and designs. It is 
likely that DOD will design high-value 
satellites, including potentially large 
constellations of strategic defense systems 
spacecraft for periodic revisit, servicing, and 
maintenance. 2 Even if the United States 
continues working in an international arena for 
space exploration, our share of the budget costs 
could be quite large. Controlling those costs 
creates a challenge for our space engineers. 
Getting down to the basics of controlling costs 
brings us back to another basic-designing for 
cost control, cost effectiveness throughout the 
system’s life cycle. If space support is to be used 
routinely, the costs per mission for accessing 
space must be iow. This extends to the costs 
associated with the vehicle, flight operations and 
the payloads. 3 

What we are doing today, both in terms of plans 
and actual building, will affect our entire 
program and shape our space future. What our 
engineers are creating in their minds today will 
be the driving force of budget problems 
tomorrow unless we show that changes in 
program strategy which include design 
constraints will not expose the overall program 
to unacceptable cost growth risks. 4 What we are 
developing in the face of budget constraints is 
very much dependent on our understanding of 
design interface. Our final designs, if they are 
going to work, must be specified in design- 
related terms that can be unambiguously 
interpreted, designed to and demonstrated. 5 In 
addition to working a design for cost 
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considerations, more attention must be directed 
toward such design characteristics as reliability, 
maintainability, human factors and 
supportability. 6 What we are considering within 
today’s budget figures must be supportable 
within the range of tomorrow’s money, for 
throughout the design process, the key words to 
remember will be operability, manufacturability, 
supportability, availability and cost- 
effectiveness. 7 

Planning for the future through design has all of 
the ILS elements working as one within and 
across specific programs. Taking those lessons 
learned from our past space flights and applying 
them in the design of our future space programs 
is not only the smart way to go, it is the only 
way to go. We cannot continue designing 
spacecraft systems without incorporating 

supportability elements. Supportability refers to 
the design of a system such that it can be 
supported effectively and economically 

throughout its planned life cycle. 8 Even while 
trying to remain competitive with other 
companies, supportability of space assets must 
be programmed in so that those assets become 
and remain vital components of an overall space 
system. These ideas, if implemented on future 
space vehicles or during block upgrades to 
existing space systems could quickly produce the 
design, employment, and capability of on-orbit 
support. 9 

Designing in on-orbit support makes sense when 
you start looking at dollars and cents in light of 
handling tomorrow’s budget. ‘Today, fully one- 
third of our space budget goes to maintaining 
the support infrastructure, buying and operating 
launch vehicles, maintaining and upgrading the 
launch infrastructure, sustaining the satellite 
control network...when you add to that one-third 
the cost of replenishing our current on-orbit 
capabilities, GPS, DSCS ...you’ve captured about 
70% of our space budget.” 7 Between our 
communications satellites, weather birds, the 
family of navigational aids and the various 
intelligence groups, we’ve got alot of space 
assets out there in various orbits depending on 
the mission. Those assets are also in various 
stages of their respective life cycles. Logistics 
support problems increase with the age of the 
system and the rate of obsolescence of the 
technology employed in its manufacture. 5 
Essentially, these space-based systems either 


directly or indirectly support all of our major 
military weapon systems. The capabilities and 
force enhancements provided by these systems 
are so important that extreme measures are 
taken to ensure their performance and 
survivability. Being able to access spacecraft 
on-orbit and perform servicing functions has the 
potential to increase performance, improve 
survivability and lower the total program cost 4 

Our lessons learned have proved to us that on- 
orbit servicing is not only feasible, but practical. 
We’ve also learned that spacecraft lifetimes of a 
decade or more are achieved with servicing. 
Properly designed spacecraft can be upgraded in 
orbit and critical spacecraft replacement 
hardware must be factored into future 
programs. 4 The concept of on-oibit 
maintenance has been proven over and over 
again, but in all instances, it was performed 
through an extra vehicular activity (EVA) on a 
specific, previously defined problem. Some of 
the missions went well and were relatively easy; 
others required more effort and time. In all 
cases, the necessary parts were packaged and 
carried out to the repair site. While this has 
worked very well in the past, our thinking and 
our planning must become futuristic. The 
changing world events and an ever-shrinking 
defense budget strongly suggest that we must 
change the way we think about things and do 
things, especially in the logistics community. 10 
Those persons involved with space programs 
need to include more thought processes in the 
design interface aspect of their programs. 
Constraints and limitations of funding, existing 
support structure, and manpower, they all must 
be addressed. The overall objectives of the 
concept development program must include 
more thoughts of integrating the future servicing 
possibility in the initial design. 

Servicing is defined as any activity performed 
on-orbit to assemble, maintain, repair, resupply, 
upgrade, deploy, retrieve, or return various 
spacecraft and/or facilities. 11 Servicing, or on- 
orbit support, covers all activities required to 
keep the space asset alive and well. Servicing 
when the parts are readily available is easier and 
in the long run, can cost less. Planning for on- 
orbit support covers all activities before launch 
and brings the future closer through the JIT 
concept 
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Planning for servicing requires more than just 
how many screwdrivers are needed. Knowing 
what is to be repaired will drive the kinds and 
numbers of tools required. The manned versus 
robotics servicing process will compel the 
engineers to be creative in their thinking. A 
robotics servicer can perform better than a 
human. Or can it? Certainly, that same robotics 
servicer can be placed in areas where it is not 
feasible for humans to be, but there are many 
other differences to consider. Once those 
differences are challenged and addressed, we 
can move forward in planning. The definition 
of servicing as defined above can be expanded to 
include not only the maintenance repair and 
resupply functions, but also replacement during 
scheduled or unscheduled servicing times. 

Any on-orbit servicing capability must start with 
a specific number and type of tools and 
equipment to perform known tasks. This 
capability for servicing depends on many things, 
but proper equipment to perform the mission is 
paramount. How many times will it be 
necessary for the astronaut or the robotics 
servicer to return for a different size tool? How 
many tools must they carry? Tools fall into 
three basic categories-existing, current 
development and recommended future designs. 
Those existing are already in the EVA 
inventory, the current development are those 
that are funded or are in prototype and the 
recommended have not passed the drawing 
board ideas . 12 What we have and what we will 
have in the future are a quantifiable item that 
can be used over and over again. Battery 
replacement for many spacecraft is a frequent 
servicing requirement Tools need to be 
standardized to cut down on numbers required 
for performing the multitude of tasks necessary. 
This would in turn benefit the entire program 
through lower costs, uniform interfaces and 
wider availability. Many existing tools were 
developed for specific tasks on specific 
spacecraft and many others were developed 
because of specific missions. A more universal 
set of tools which could be applied to servicing 
on all spacecraft would be desirable and would 
result in lower transportation costs and less 
EVA crew training. 

Fuel/fluid replenishment is another aspect of 
servicing to consider. A major drawback with 
fuel/fluid replenishment is the standardization-- 


or non-standardization-of the connectors in use 
in the various spacecraft families. In order to 
handle this type of servicing, it would be 
necessary to develop the necessary connectors 
and have a variety of them available for use. 
However, there are many spent craft that cannot 
be refueled because that capability was not 
designed into them. This design flaw has left us 
with basically one support concept and that is 
abandonment. We cannot do any space-based 
on-orbit servicing and in most cases, there is no 
fuel or not enough fuel left to bring the space 
asset back to earth. An empty fuel tank is 
certainly the most obvious life-limiter of our 
space assets . 7 

So, what’s being done? Abandonment of a 
single satellite might be acceptable if that 
satellite has repaid its initial costs twice over, 
but the concept of abandonment of large and 
expensive satellites, such as Milstar, is 
counterproductive in a time of reduced budgets. 
Some space vehicles are outliving their expected 
lifetimes. This is great. Others are not. 
Perhaps the argument could be for abandonment 
of those systems, but is it reasonable and even 
prudent to abandon them? Our space engineers 
are limited only by their thinking. And their 
thinking is hampered by dwindling budgets. 
And yet, studies have shown that no technology 
breakthroughs are required to perform on-orbit 
servicing of space systems . 9 Many of the 
systems, if repaired while orbiting, could carry 
out their respective mission even though more 
advanced technology will be used on later 
vehicles. Most existing space assets can be 
serviced and future families of satellites can be 
designed few on-orbit servicing to include 
replacement of parts and replenishment of 
fuels/fluids. Some of these will be necessary 
with robotics equipment, but many can be 
accessed by humans. In either case, the space 
community must expand beyond today’s designs 
and produce those families of future satellites 
which operate at the efficiency we expect and 
operate within budget constraints. Life-cycle 
costs and improved system effectiveness can be 
undertaken through standardization of those 
elements that are similar across system 
boundaries. 

Those satellites that cannot be supported by 
human astronauts must be capable of accepting 
robotics intervention. That family of satellites 
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that is beyond the reach of our human capability 
can still be serviced and maintained. But, by 
today’s standards, we still can and must take 
care of what’s out there with what we have - and 
without the standardization of tools and 
fuel/fluid connectors, our servicers (both human 
and machine) must carry an array of extra tools. 
This possibility will not always be acceptable. 

Let's take a look at what we have and what we 
can do with it. The very idea of a storage unit is 
nothing new, but where do you put it and what 
do you put in it? There are certain orbits which 
can be used where an object that is orbiting will 
continue at that specific orbit almost 
indefinitely. These orbits can be used to hold 
that storage unit. There are five of these orbits, 
Libration Points, also known as Lagrangian 
points for Earth-Moon orbits as well as similar 
points for Sun-Earth, Sun-Venus, and Sun-Mars 
orbits. Two of these Lagrangian orbits in Earth- 
Moon location are very stable and require a 
minimum of energy for an orbiting storage unit- 
-a parts servicer. A parts servicer is simply a 
vehicle that holds the various and assorted tools 
necessary for servicing those satellites within 
orbital reach. This parts servicer can be placed 
in a strategic position for easy access by any 


Orbital Maneuvering Vehicle (OMV). Many of 
the satellites we would want to service are out of 
human reach and would need to be serviced 
through robotics intervention. The robot that is 
being sent to perform the servicing can easily be 
attached to the OMV. The number of parts 
servicers needed would be based on orbits 
available and numbers of satellites easily 
reached within each orbit. Based on reliability 
predictions, the parts servicer would be outfitted 
with parts specific for those satellites to be 
serviced and planned satellites to be launched. 
Based on design interface, the parts servicer 
could be available and ready when needed or 
Space-Based JIT. 

Just to prove a point, that of cost savings, look at 
some tables that represent launch costs for some 
specific vehicles. These vehicles were chosen as 
all launch into Low Earth Orbit (LEO), 
Geosynchronous Transfer Orbit (GTO) and 
Geostationary Earth Orbit (GEO). Their weight 
loads range from 1,420 kg on the smaller Delta 
Payload Assist Module (PAM) to 4,600 kg for 
the larger Titan IV. 


Unit Cost ($M) Cost/kg ($k/kg) 



1978 

1984 

1990 

1990 

GTO/GEO 

Delta PAM 

20 

35 

55 

38.7 / N/A 

Atlas G 

31 

50 

72 

30.5 / 54.6 

Titan IV 

73 

96 

264 

22.0 / 57.4 


Figure 2 Launch Costs History 


Simple math of cost per kilogram times weight load produces the next figure. 


172 


American Institute of Aeronautics and Astronautics 



Vehicle 

Weight Load 

Launch Cost 


GTO/GEO 

GTO/GEO 

Delta PAM 

1,420 / N/A 

54,954 / N/A 

Atlas G 

2,364 / 1,330 

72,102 / 72,618 

Titan IV 

12,000 / 4,600 

264,000 / 264,040 


Figure 3 Costs per Launch 


As we look at the figures represented above, 
simple economics tells us that contin ual 
replacement of any satellite family is expensive. 
The 1990 figures are almost triple the 1978 
figures and will very likely continue to increase 
even more. The more we can put into orbit at an 
acceptable, lowest-possible cost, the more 
efficiently our space program will operate. One 
or two launches of the parts servicer on a Delta 
PAM into Libration Points could hold down the 
weight on payloads put onto an Atlas G or a 
Titan IV by having repair parts already in orbit 
waiting. One or two launches of a Delta PAM 
carrying an on-orbit parts servicer saves a great 
deal of money when compared with the launch 
of a heavier vehicle carrying a replacement 
satellite that has no on-orbit capabilities. 

As we think more about a parts servicer orbiting 
with assorted parts stored, waiting for the time 
when there is a need, the idea of design interface 
begins to take on a new dimension. We simply 
cannot be cost effective while we store six or 
eight of one type part for various satellites. We 
need to design in and enforce some sort of 
standard in order to reach the point where we 
need store only one or two parts at the most. 
Satellites need to be designed for refueling and 
the ports for each unit must be within certain 
standards to allow use of one or two couplers for 
the vast majority of them. The interface 
between modules and the other parts of the 
satellite could be unique to each satellite design 
if necessary, but appears to be a good candidate 
to become a standard. It would allow the 
stowage of orbital replacement units from more 


than one satellite in the parts servicer. 
Standardization becomes a primary means of 
lowering life cycle costs and providing improved 
system effectiveness. 12 

Space logistics must become an increasingly 
critical element of the planning, design, 
development, and operation of future space 
systems— both manned and unmanned. The 
complex new challenges to be introduced in the 
emerging field of modem space logistics 
demand early recognition and planning by those 
in the related disciplines, in order to provide 
effective solutions to problems affecting 
program goals accomplishment and 
affordability. 2 Space-Based JIT becomes a vital 
link between the life cycle prediction and the life 
cycle actuality. Budget constraints already make 
it more economical to consider repair vice 
replacement of assets. With some repair parts 
already in space, payloads would be smaller and 
launch costs would reflect the weight reduction. 
With design interface considered, future 
satellites— standardized satellite— would be 
launched into orbits where they can be reached 
by the parts servicer and serviced when needed 
to extend their expected lifetimes. All things 
considered, some standardization of space assets 
through design interface incorporates many 
issues beyond just design changes. The outcome 
of the design process concerning space support 
issues which eventually effect budgets far 
outweighs the problems caused by making no 
changes at all. Logistics support has taken on a 
new urgency when we consider the space arena 
and that urgency must be met if we are to be a 
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vital part of the space world, in today's markets 
with today's money. Supportability has never 
seemed so critical, has never been so important 
until this time of ever-shrinking budgets, scarce 
resources and increasing demands made on the 
space asset. The support of a satellite system is 
vital, no matter the mission of that system. Our 
repair robot or astronaut must be able to have 
the proper equipment to do the best job possible 
and the time is coming when we will not be able 
to launch everything we need in one package. 
We must have the means to put some of the 
more frequently used parts in a place where they 
can be stored, waiting for use-Space Based JIT. 
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Abstract 


This paper describes an approach to improve 
availability by testing redundant parts at pre-determined 
intervals. The purpose of the testing is to detect non- 
functional back-up equipment and develop work-around 
measures or replacement spacecraft before a failure of 
the primary equipment reduces availability. The work 
reported here is an outgrowth of the NASA Space 
Network's program for the maintenance and 
replenishment of the Tracking and Data Relay Satellite 
System. 

The approach is based on a standby factor and a 
cyclic stress factor. The standby factor accounts for the 
effects of adverse storage conditions encountered as 
part of the in-flight environment. The stress factor 
accounts for the effects of physical or thermal cycling 
due to the application of force or power that 
characterizes the operation or use of a component. 

By the quantitative consideration of standby and 
cycling risks, a regular testing interval can be calculated 
- an interval for testing that furnishes information for 
availability planning but does not subject the spacecraft 
to undue risk. This paper includes quantitative 
solutions for appropriate testing intervals for equipment 
configurations and failure rates that are representative 
of a Tracking and Relay Data Satellite. The effect of a 
single test on the availability of certain equipment is 
also illustrated. 


A 

Ab 

Ap 

C 

F 

Fb 

L 

NTB 

Q 

R 

S 

t 

tf 

ti 


Nomenclature 

availability of service 
availability of back-up unit 
availability of primary unit 
cyclic test stress in ^-equivalent time 
failure probability of service 
failure probability of back-up unit 
limitation on life of spacecraft 
net testing benefit 
standby factor on failure rate 
response time after failure 
shortfall in service availability 
time in future 
time in flight 

time interval for prediction 
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Ub 

Up 

u 

X 

a 

P 


unavailability of back-up unit 
unavailability of primary unit 
unavailability of service 
failure rate of operating unit 
scale parameter in Weibull formula s 
shape parameter in Weibull formula o -i 


I. Background 


a/6 


6 A 




The NASA Space Network includes five 
geostationary Tracking and Data Relay Satellites 
(TDRSs) controlled by ground terminals located 
primarily at White Sands, New Mexico. The TDRSs, 
from their high orbits, can view almost the entire 
surface of Earth. Each TDRS relays commands from a 
ground terminal to user spacecraft in low earth orbit 
(LEO). Each TDRS also relays data and telemetry from 
user spacecraft to the ground terminal. User spacecraft 
benefit from the Space Network's ability to 
communicate between fixed ground facilities and 
rapidly moving spacecraft at almost any time, and at 
almost any location in LEO. 

To ensure the continuity of Space Network 
services, NASA monitors the state of health of the 
TDRSs, plans for changes in user requirements, and 
replaces or supplements TDRSs as necessary. 
Constellation replenishment planning depends on 
accurate estimates of TDRS lives. TDRS lives are 
predicted by reliability models. These models perform 
Monte Carlo simulations of the failures of all 
components except those already known to have failed. 

In most cases, a TDRS has a primary and a back-up 
component for each required function. Thus, except for 
the time required to identify a failure and activate the 
back-up component, most component failures do not 
reduce the availability of TDRS communication 
services. A partial or complete communication failure 
occurs only if both a primary component and its back- 
up components fail. Back-up components are either 
active (e.g., connected to live electrical circuits, and, as 
a result, warmer than their environments) or inactive 
but ready to be activated by an up-linked command to 
throw a switch. 
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TT. Approach 

Availability Improvemen t bv In-Flight Testing 

The NASA Space Network's TDRS's are not 
normally subjected to in-flight testing of spare 
components because the tests involve risk and expense. 
In the absence of in-flight testing of a spare 
component, the availability of the component type in a 
redundant configuration depends on two factors. The 
first factor is the availability of the primary component. 
The present functionality of the primary component is 
assumed to be obvious because it is in use. However, 
the primary component is subject to the possibility of 
failure at any future time. If its failure rate X (often 
obtained by using MIL-HDBK 217^) is constant, then 
its availability A p after a time interval tj is: 

A p = e-^i (1) 

and its unavailability is the complement of the 
availability, i.e.: 

Up = 1 - e-^i (2) 

The second factor is the availability of the back-up 
component. The back-up component, or its switching 
circuit, could be in a failure state that will not be 
apparent until the item is switched on or otherwise 
placed in active service. Its exposure to environmental 
factors such launch acceleration and vibration, vacuum 
with out-gassing, ionizing radiation, and thermal 
cycling could have been responsible for its latent failure 
state. Alternatively, the passage of time alone could be 
responsible for its internally generated physical or 
chemical degradation to a latent failure state. The 
availability Ab depends on the standby factor Q 
multiplied by the failure rate X, and on the accumulated 


time in flight (since checkout) tf 

Ab = e-Q^f (3) 

and the unavailability is the complement of the 
availability, i.e.: 

Ub = 1 - e-Q Xt f (4) 

The overall risk of unavailability U is the product of the 
two factors: 

U = Up U b (5) 

Substitution gives: 

U = (1 -e- Xt i)(l -e-Q^f) (6) 


The overall availability for the case without in-flight 
testing is the complement of the unavailability: 

A = 1 - (1 - e-**i) (1 - e-Q^f) (7) 

If in-flight testing is under consideration, the 
predictive time interval t; between tests should not 
exceed the time required for the implementation of 
alternative back-up or work-around measures. 
Furthermore, the accumulated time in flight tf should 
not exceed the time required for the completion of the 
spacecraft's mission. In the meantime, there is an 
expected value for the shortfall S in spacecraft-years of 
service availability, depending on the time R required to 
respond to the failure: 

S = U R (8) 

Substitution gives: 

S = (1 - e'^i) (1 - e’Q Xt f) R (9) 

Risk of In- Flight Testing 

In-flight testing of a spare component could result 
in a failure because of the cyclic stress due to each test 
itself. The stress can affect the switch that applies 
power to the spare, the switch that connects the spare to 
other devices, and the spare equipment itself, but these 
phenomena are treated together for the purposes of this 
paper. If we assume that the cyclic stress C is given in 
1-equivalent hours of failure risk per in-flight test, then 
the failure risk to the spare component due to each test 
is: 

Fb = l-e-»C < 10 > 

Since the overall risk results from the failures of both 
the primary and the back-up components, the expected 
value of failed spacecraft-years F in terms of potential 
spacecraft life (since launch) L is: 

F = U a Fb (11) 

Substitution gives: 

F = (1 - e’^i) (1 - e'^ c ) (L - tf) (12) 
A ppropriate Testing Intervals 

In-flight testing of a back-up component could be 
beneficial if the shortfall S in spacecraft service 
expected during the failure response period is 
significantly greater than the testing stress failure 
expectation F. The in-flight testing of spare 
components would not prevent any failures, but it could 
facilitate operational planning to maintain service and 
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to obtain value from the programs being served. TDRS 
services are believed to be much more valuable than 
TDRS costs, because the services are needed by many 
user spacecraft that may greatly exceed TDRS in cost 
and value - but only if a TDRS can return their data. 
TDRS user spacecraft programs include the following: 


AXAF Advanced X-Ray Astrophysics Facility 

COBE Cosmic Background Explorer 

EOS Earth Observing System 

ERBS Earth Radiation Budget Satellite 

EUVE Extreme Ultraviolet Explorer 

GRO Gamma Ray Observatory 

HST Hubble Space Telescope 

ISSA International Space Station Alpha 

LSAT Landsat 

SS Space Shuttle 

TOPEX Ocean Topography Experiment 

TRMM Tropical Rainfall Measuring Mission 

UARS Upper Atmospheric Research Satellite 

XTE X-Ray Timing Explorer 

Furthermore, in-flight testing of spare components 
could enable expensive and time-consuming 
procurements of replacement spacecraft to be either 
accelerated or delayed, whichever may be appropriate, 
depending on the functionality of the in-flight 
equipment. 

For these reasons, advanced knowledge and 
prevention of potential spacecraft service shortfalls 
could have value comparable to, or greater than, the 
spacecraft themselves. Assuming that the values of S 
and F are comparable directly, the net testing benefit 
NTB in spacecraft-years can be defined for any test 
event as: 

NTB = S -F (13) 

Substitution gives: 

NTB = (1 - e’^i) (1 - e"Q^ T f) R 
- (1 - e'^i) (1 - e'^ c ) (L - tf) (14) 

For application to a periodic testing program, the NTB 
must be summed over the life of the spacecraft. Note 
that small testing intervals may not be practical if they 
result in cycling that approaches or exceeds the finite 
life of a component, which is not considered in the 
above constant failure rate-based equations. Also note 
that the implementation of small testing intervals could 
be costly, reducing the NTB. 


IB. Examples 

Cyclic Stress and Testing Interval 

The first example illustrates the determination of an 
appropriate testing interval. The numerical values used 
here are typical of many TDRS components that are 
configured with an active primary unit and an inactive 
back-up unit that is switched on if and when it is 
needed. A typical failure rate X for the active 
component is one failure per million hours and the 
standby factor Q for the back-up component is 0.1, in 
accordance with standard failure rate data 1 and project 
documents 2 " 4 . The response time R (based on the 
highly variable average time to build and launch a 
replacement spacecraft) is estimated at three years, and 
the lifetime L of a spacecraft is estimated at 15 years 
(also an uncertain estimate, probably by plus or minus 
five years). On the basis of the above formulas used in 
spreadsheet calculations, the testing interval ti that 
maximized the net testing benefit NTB was evaluated as 
a function of cycling stress C in ^-equivalent hours 
(see Figure 1). 

For low values of cyclic stress, the test interval is about 
one month. As cyclic stress increases to about 2000 
hours, the testing interval increases to about one year. 
At higher cyclic stresses, the testing interval continues 
to increase, indicating that testing may not be 
appropriate. It may therefore appear that cyclic stress 
needs to be determined before choosing a testing 
interval. However, this probably is not the case. The 
reason is that the net testing benefit for the entire range 
of cyclic stress is only about 0.001 spacecraft-years. 
This NTB appears to be too small to justify a testing 
program. 

Cyclic Stress and Net Testing Benefit 

The second example involves a component 
configuration in which the back-up equipment is active 
(e.g., connected to live electrical power supplies) but 
its functionality is not known until it is switched into 
actual use. An example is the transponder in TDRS’s 
tracking, telemetry, and command (TT&C) subsystem 
(though a small fraction of the back-up equipment is not 
active). Numerical values are the same as in the first 
example, except that the failure rate X is one failure per 
100,000 hours and the standby factor Q is 1.0. These 
higher values greatly increase the net testing benefit. 
The testing interval that maximizes the NTB is 
determined to be about two months, independent of 
cycling stress. However, the NTB does depend on 
cycling stress (see Figure 2). 


In this example, the cyclic stress must be known, 
not to determine test interval (which is about two 
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months for all cyclic stresses shown), but to determine 
whether testing is beneficial. However, because the 
back-up unit is powered continuously whether tested or 
not, the stress of testing appears to be small, almost 
certainly less than 1,000 hours based on the author's 
subjective estimate. Therefore, testing appears to be 
beneficial by affording an expected value of almost two 
years of notice of an impending failure. For 
comparison, the expected value of additional spacecraft 
failure-years attributed to the testing is less than 0.1 
years. 

Spacecraft R eliability and Useful Life 

The third example involves TDRS 1, which was 
launched on April 4, 1983, and, at an age of about 12 
years, is operating beyond its design life. There has 
been no testing program for the TT&C transponder on 
TDRS 1. Therefore, the back-up transponder's 
functionality is not known. According to a MIL-HDBK 
217D-based, parts-count, Monte Carlo reliability model 
shown here only schematically (see Figure 3), if the 
back-up transponder were to be tested successfully, the 
prospects for the life of TDRS 1 transponder 
functionality would improve markedly (see Figure 4). 

With no test, the predicted availability of the TDRS 
1 TT&C transponder fits a two-parameter Weibull 
formula: 

A = e-0/a)P (l5) 

in which the scale parameter a is 18 years and the shape 
parameter (J is 1 .23. The future time t is limited to eight 
years because by then the satellite will be at the 
approximate limit of its foreseeable useful total life of 
about 20 years. The nearness of the shape parameter to 
unity indicates that the 12 year old back-up equipment 
is probably no longer fully functional. The mean 
remaining life of the TDRS 1 TT&C transponder is 6.8 
years. 

If a test is performed and shows that the back-up 
equipment is fully functional, a would increase to 23 
years, indicating that the life of the transponder is likely 
to be longer, and p would increase to 1.64, a value that 
indicates the presence of redundancy. The mean 
remaining life of the TDRS 1 TT&C transponder would 
increase to 7.5 years. 

However, if the test is performed and shows that 
the back-up equipment is non-functional, a would 
decrease to 1 1 years, indicating that the life of the 
transponder is likely to be shorter, and P would 
decrease 


to 1.00, a value that indicates the absence of 
redundancy. The mean remaining life of the TDRS 1 
TT&C transponder would decrease to 5.6 years. 

IV, C onclusions 

The in-flight testing of spare components, while 
increasing rather than reducing failures, could be 
beneficial if the knowledge of back-up functionality 
were used to prepare and implement responses to 
impending failures. However, as shown by the first 
example in this paper, the testing would not be 
appropriate for most back-up components on TDRS, 
because their estimated failure rates are too low to 
produce a significant benefit. This result is consistent 
with the NASA Space Network practice of not normally 
performing in-flight testing of spare TDRS components. 

In some cases, the in-flight testing could be 
appropriate. These cases can be identified by their high 
estimated failure rates for both the primary and the 
back-up components. The most likely candidate on a 
TDRS appears to be the TT&C transponder. Of course, 
the type of screening analysis shown in this paper is not 
sufficient to warrant the implementation of an in-flight 
testing program for the transponder. Failure rates, 
failure modes, standby factors, cyclic stresses, wearout 
phenomena, and the likelihood of test results affecting 
future operations or procurements would all require 
more detailed evaluations before deciding on whether to 
test in-flight. For example, the historical TDRS TT&C 
transponder failure rate appears to have been lower than 
the MIL-HDBK 217D rate, and a reduction in the rate 
would reduce the net benefit of testing. Nevertheless, 
further evaluation of the possibility of in-flight testing 
appears to be worthwhile. 
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Introduction 

In this age of shrinking resources, cost avoidance 
has become as critical as direct cost savings. There 
is no doubt that Effective Transition Management 
achieves this aim. 

What then, is Effective Transition Management and 
how does it achieve its goal? It is the introduction 
and use of a hierarchical decision model and 
computerized tracking system which successfully 
integrates capital acquisition into the support base. 
You will discover that because this proven system is 
generic, compatible and flexible, its applications are 
virtually unlimited. It is this highly dynamic process 
which I would like to share with you. 

Skilled specialists are now rotated rapidly through 
acquisition programs on a requirements-driven 
basis. Managers continue their quest for inefficient 
areas to trim, slash or cut. However, there is one 
area of operations in every major corporation and 
government department that, as yet, has not 
received the attention it deserves. This essential 
element is Transition Management. 

Capital acquisitions, at some point, must be handed- 
off to a support matrix for the "in-service” phase of 
their life cycle. Most of us who have been on the 
receiving end can usually cite outrageous examples 
of adjustment, recovery or disaster. This means 
buying what amounts to a second initial sparing 
package, re-aligning the range and depth of 
inventory to match a changed maintenance concept, 
interpreting contractor-developed configuration 


control data or ensuring that the latest information is 
contained in the technical publications. This list is 
endless. For major purchases, this "in-service” phase is 
often fifteen, twenty or more years. The least 
desir\able, yet most common condition, is to suffer up 
to five years of recovering from errors or omissions after 
the transition to the support matrix occurs. Without 
Effective Transition Management, making new 
equipment fully operational may thus become a long and 
costly process. 

Scope 

This process applies to any organization which is buying 
capital equipment and which is then required to 
maintain the support of that equipment during its 
ensuing in-service life cycle. 

Concept 

The concept of Effective Transition Management has 
two objectives. The first is the identification of 
resources and timings to facilitate the long range 
planning and programming. The second is the 
development of a check list and procedures to smoothly 
execute the transition of the capital equipment systems 
management responsibilities from the Program/ Project 
Manager to the lead Matrix Support Manager. 

A Transition Plan should be prepared at the earliest 
possible date in the life of the project, usually two years 
before the transfer is scheduled to take place and must 
be approved by senior management. Normally, the 
transfer will be for complete systems. However, in 
certain instances, a system may be introduced by 
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components, in which case the plan should follow a 
phased approach. As above, the Transition Plan for 
the first component will normally be prepared at 
least 24 months before it is transferred to the lead 
Matrix Support Manager. 


CONCEPT 

• IDENTIFY RESOURCES 
AND TIMINGS FOR LONG 
RANGE PLANNING 

• DEVELOP CHECKLIST AND 
PROCEDURES TO 
EXECUTE SMOOTH 
TRANSITION 


Definition of Terms 

1. Transition Plan (TP) , 

• The document which outlines actions, 
responsibilities and agreements relative 
to transferring systems management 
from the program /project to the support 
matrix. It contains a schedule of events 
for an orderly and timely transfer of 
systems management responsibilities and 
addresses resource implications. Senior 
management will normally approve the 
Transition Plan. 

2. Transition Plan Steering Committee (TPSC) . 

• The TPSC is a decision level group 
comprised of the Program /Project 
Manager and key Support Managers or 
their representatives involved in the 
introduction and support of the newly 
acquired system. 


3. Transition Plan Working Group (TPWGT 

• The TPWG is a Working Group of 
program/project and matrix representatives 
whose responsibilities include developing the 
Transition Plan detail and executing the 
detailed transition activities. Membership, as 
a minimum, will include the losing and 
gaining managers. The size and scope of the 
TPWG will depend upon the size and 
complexity of the program/project. Lead 
responsibility lies with the Program/Project 
Manager. In general, the chairmanship of 
the TPWG is delegated to the project’s 
Integrated Logistics Support (ILS) Manager 
and the gaining lead Matrix Support Group’s 
Transition Manager becomes the deputy of 
the TPWG. Members of the TPWG are 
those who are designated as support staffs 
and subject matter experts of the various 
related activities usually listed in an 
Implementation Plan. 

4. Transition Manager . 

• The Transition Manager is the individual, 
nominated by the lead gaining Matrix 
Support Manager and approved by senior 
management, responsible to ensure that 
Transition Plans prepared for the system (s) 
to be handed over to the in-service support 
matrix are successfully concluded. 

5. Matrix Manager . 

• A Matrix Manager is an individual in the 
fixed array with cognizance for the staff and 
area of expertise that the program /project 
office draws upon to carry out its 
responsibilities. 

6. Senior Review Board (SRB) . 

• A senior decision-making body normally 
chaired by the senior manager and 
comprised of permanent core members 
determined by areas of responsibility. 
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7. Master Transition Agreement and Schedule 
(MTAS'l 

• The coordinating schedule for 
identifying the losing and gaining 
managers, equipment transition dates, 
and resource impacts, as well as all 
agreements between gaining and losing 
organizations. The MTAS is a living 
document agreed to by all levels of 
management up to the SRB or senior 
manager as applicable. It will be 
published semi-annually or more 
frequently, as required. 

Applications 

The transition of each system or major component 
will be tailored to the level of management required 
and the ability of the gaining organization to assume 
system responsibility. If the prime equipment exists 
or if there is an association with existing equipment 
already being managed, the new system or 
component shall go to the office with the equipment 
unless otherwise directed by the SRB. 


APPLICATIONS 

• TAILORED TO LEVEL OF 
MANAGEMENT REQUIRED 

• ABILITY OF GAINING 
ORGANIZATION TO ASSUME 
SYSTEM RESPONSIBILITY 

• NEW SYSTEM NORMALLY 
DESIGNATED FOR OFFICE WITH 
EXISTING EQUIPMENT 


Formal Organization 

Transition Planning is based on the efforts of two 
organizations, the Transition Planning Steering 
Committee (TPSC) and the Transition Planning 
Working Group (TPWG) which may entail ancillary 


TPWG Sub-Working Groups. Figure 1 illustrates their 
relationship to the Senior Review Board (SRB). 

The TPSC is normally formed at least two years prior to 
the required transition date. The TPSC consists of the 
Program/Project Manager and key support managers or 
their representatives from all the areas of responsibility 
involved with the Materiel Management of the system 
being introduced. 

The TPSC’s function is to oversee the transition of the 
Materiel Management of the system to the in-service 
support matrix. Subordinate to the Steering Committee 
is the Working Group consisting of a Chairman (the 
Program/Project ILS Manager), a Deputy (the 
Transition Manager), a Secretary (a designated Working 
Group member), regular members (pertinent support 
staffs) and ad hoc members (representing all subject 
matter experts in areas addressed in the Implementation 
Plan on a consultative basis). 

Sub-Working Groups will be formed by the TPWG on 
an as required basis. The membership will be 
representative of the subject matter under consideration. 

Responsibilities of the Groups 

The losing and gaining managers are jointly responsible 
for system/ component transition. Each transition will 
occur at an agreed-upon date and under agreed-upon 
conditions. The overriding factor is that the operational 
management of the existing system(s) will not be 
adversely affected as a result of a system or component 
in transition. 

A Transition Manager will normally be appointed by the 
gaining Life Cycle Management component. However, 
other options are either to establish a position in the 
capital project when the personnel requirements are 
being identified and staffed, or utilize an appropriate 
program/project manager who is intended to move to 
the managing component when the program /project is 
complete. The term Transition Manager may or may 
not include other staff which will be determined by the 
level of effort required. When the prime contract has 
been signed, the Transition Manager will likely reside 
in the program/project management office. The 
Transition Manager will remain there until the major 
share of the Transition Plan has been completed. 
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RESPONSIBILITIES 

• JOINT 

• AGREED CONDITIONS 

• MAINTAIN OPERATIONS 
MANAGEMENT READINESS 


Functioning 

The chairmanship of the Steering Committee is the 
joint responsibility of the Program /Project Manager 
and the lead Matrix Support Manager (co-chaired). 
The Steering Committee reports to the SRB 
through the Program /Project Manager. 

In the TPWG, each Sub-Working Group (SWG) 
Chairman provides a monthly written progress 
report to the Working Group Chairman. These 
reports are normally reviewed by the Transition 
Manager. From these reports and the TPWG 
meetings, the Working Group Chairman brings 
forward to the Steering Committee any unresolved 
item(s) considered beyond the scope/authority of 
the Working Group and provides regular updates on 
the progress of the Working Group. 

The TPSC is intended to be few in numbers yet 
have enough authority to make most decisions 
without seeking the approval of higher management. 
Members are chosen from areas considered vital to 
the success of the transition; ie the Program/Project 
Manager, the lead Matrix Support Manager and 
other relevant matrix support managers. The 
Chairman of the Working Group, on the other 
hand, is mandated much narrower parameters of 
autonomy and authority. Progress is to be reported 
to the Steering Committee and action is to be 
agreed to by the Steering Committee. The TPSC is 
a decision-making body which chooses between 
alternatives presented by the TPWG and 


investigates the broader policy implications. If the 
proposed solutions exceed their authority, the 
Program/Project Manager is responsible for presenting 
agreed upon options to the SRB. The TPSC is 
co-chaired by the Program/Project Manager and the 
lead gaining Matrix Support Manager. 

The TPWG is charged with preparing and implementing 
the Transition Plan. The TPWG is responsible for 
identifying the areas that require investigation and 
setting up the Sub-Working Group(s) to carry out the 
investigation. If the proposed solutions can be 
implemented by the TPWG no further action is required 
except to inform the TPSC. If not, the problem is 
passed to the TPSC for resolution. The TPWG is 
normally chaired by the project ILS Manager with the 
Transition Manager as deputy. 

The TPSC should hold a meeting at least every six 
months (more frequently depending on activity). There 
will normally be two Working Group meetings for every 
TPSC meeting. Sub-Working Group (SWG) meetings 
are less formal and more frequent. Each SWG 
Chairman provides a monthly written progress report to 
the Working Group Chairman through the Transition 
Manager. The Working Group Chairman will bring 
forward to the TPSC any unresolved items(s) considered 
beyond the scope/authority of the Working Group and 
provides regular updates on the progress of the Working 
Group. 

The format used at the TPSC meetings will be to review 
previous minutes and be updated by the TPWG 
Chairman on the progress of the Transition Plan. This 
is to be followed by the tabling of unresolved items with 
available options for discussion and resolution/decision 
by the TPSC. 

The established governance structure at Figure 1 will be 
used to escalate unresolved items for 
direction/arbitration where required. 

The Transition Plan is deemed to be approved once all 
members have signed off and the presentation has been 
accepted by SRB or the applicable senior manager. 

The Master Transition Agreement and Schedule 
(MTAS) should be revised every six months or more 
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frequently as directed. 

Contents of the Transition Plan 

The following is a list of the major elements and 
reports (examples given illustrate an ima ginar y 
status as of Dec 4, 2000) in the Transition Plan: 

• the Transition Plan Data Flow 
(Figure 2); 

• a recommended list of Transition Plan 
Work Packages from the Work 
Breakdown Structure; 

• the MTAS report for the complete 
system to be transitioned showing by 
percentage those Work Packages 
remaining incomplete and those already 
100% completed. This provides an 
overview of the project’s current status 
at a glance; 

• a second report showing only the 
incomplete Work Packages rem ainin g to 
complete the transition; 

• a breakdown by functional group within 
the project of progress-to-date and an 
average percentage completed; 

• a third report providing a breakdown of 
all incomplete tasks by functional group 
and an average percentage completed; 

• the "key" graph which illustrates current 
System Transition Progress. This graph 
is produced automatically when linked 
to the database. When the database is 
posted up-to-date, a graph may be 
produced showing Management at a 
quick glance, the status of the project, 
equipment system, subsystem, or 
component, depending on the data kept 
in the database; (Figure 3 - "a picture is 
worth a thousand words"); 


• each task may be subdivided into as many 
subtasks and sublevels as management 
considers necessary; 

• an iterative process may be used; and 

• a suggested handover document to be used 
when the transition is completed. 

Additional information may be tracked by expanding 
tasks at the subtask level, for example: 

• financial assistance required by line 
organizations involved in the transition 
process; 

• training required by the matrix and the lead 
time necessary to get that training; 

• short/long term manpower/ funding 
required by the matrix; 

• tools and test equipment in an automated 
environment required to manage the in- 
service life cycle phase; 

• maintenance of warranties and the follow-on 
buys that are a continuation of the same 
system; 

• publications to be transferred such as: 
specifications, independent evaluation plans, 
results of any trials/test including the raw 
data, and the management of the database 
and selection of tools required for its life 
cycle management; 

• maintenance and tracking of engineering 
change proposals, design change proposals 
and failure reports to be transferred to the 
matrix life cycle managers; and 

• lastly, initiation of the replacement system 
and necessary studies, if required. 


American Institute of Aeronautics and Astronautics 


185 


Note: 


Due to individual requirements of each project, 
this is not meant to be an exhaustive list but 
only to Hi ghli ght the main tasking areas which 
most programs/projects must address. 

Responsibilities of the Transition Manager 

The Transition Manager must be responsible to 
ensure that Transition Plans prepared for system(s) 
to be handed over to the in-service support matrix 
are successfully concluded: 


TRANSITION MANAGER 

• NORMALLY FROM LEAD 
MAINTENANCE ORGANIZATION 

• ENSURES PLANS PREPARED 

• BRINGS TRANSITION TO 
SUCCESSFUL CONCLUSION 


• by developing, maintaining and 
controlling the overall time line 
transition schedule; 

• by assuring that all transition issues are 
brought to a successful! conclusion. 


Major Marty Burke is Faculty Head for Materiel 
Management Training at the Canadian Department 
of National Defence Headquarters in Ottawa, 
Canada. He is responsible for major training 
programs in Project, Life Cycle and Procurement 
Management. In addition to completing graduate 
studies in Logistics Management, he is a Logistics 
Specialist in the Canadian Air Force. 
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TRANSITION PLAN 

GOVERNANCE STRUCTURE 










TRANSITION PLAN DATA FLOW 




Figure 2 Transition Plan Data Flow 






Figure 3 Transition Plan Progress 
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Abstract 

To keep in tune with the rapidly 
changing "Hardware" technology, it is 
imperative that all of the "Supporting” 
components of a program's efforts reflect 
these increases in technology. To maintain a 
work force that keeps in tune with the ever 
increasing technology base, training needs to 
remain a major consideration in all types of 
organizations. 

This paper focuses on the area of 
training and education and suggests a 
reasonable, cost effective alternative to 
carrying the entire burden of developing, 
training and maintaining a workforce in a 
rapidly changing, highly technological 
environment. 


Introduction 

It has been known that one of the 
most important and costly components of a 
company's make-up is that of training. With 
the current state of the economy, it is 
becoming increasingly more difficult, in terms 
of time and money to adequately train 
individuals to perform in today's high tech 
environments with any degree of competency. 

This is even more imperative when 
one looks at the mission of organizations such 
as government. The government has a 
requirement to maintain a highly trained 
workforce for internal operations and, due to 
downsizing, incurred a requirement to take on 
work previously handled by contractors and 
consultants. 
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In a large number of organizations, be 
they commercial or government contractors, 
training/education was seen as a "necessity"; 
however, during lean times, the training of 
individuals is often one of the first areas to be 
drastically scaled back, with even whole 
departments being eliminated. 

Today, to reduce operating costs 
within the government arena, we are seeing 
more and more jobs, that were considered 
contractor jobs, being performed by 
government personnel. These jobs range 
from office support to highly skilled, 
engineering related. 

With earlier technology, it was 
possible to "Develop" individuals based upon 
the experience of the senior members of the 
organization. The scenario within the 
government area is that some of the jobs 
being taken over were not performed by 
government employees. Therefore, "senior 
personnel" are not becoming trainers of the 
junior personnel. Add on to this the fact that 
training is rapidly becoming more costly and, 
due to rapidly advancing high technology, 
even the senior level personnel have 
requirements to be trained. 

Current technology is software 
intensive, the amount of code written to 
operate and support current systems has 
increased geometrically. Space systems 
being developed require "training" over and 
above current practices. We are in a high 
technology environment, the computers and 
machines of ten years ago have grown in 
technology by leaps and bounds. 
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Customers of high technology 
systems realize that the training, needed to 
support the system is very costly and that 
they are becoming more actively involved in 
operational aspects of the systems; therefore, 
the customer workforce needs to reach the 
level of maturity that the contractor's 
personnel are at. This will allow for a 
smoother transitioning period to occur. 

Reason For Training 

The following represents three (3) reasons 
why training is needed: 

1 . Program requirement. This is 
found on the majority of high technology 
government contracts. The contractor 
develops the product, and since the customer 
probably has no experience with the piece of 
hardware, operator and maintainer training is 
required to support the equipment. The cost 
of the training development is borne by the 
customer and is included as a line item in the 
contract. 

2. Purchase of a new piece of 
hardware and/or software for conducting day 
to day business. Here the company has 
purchased hardware or software for achieving 
the goals of the organization in a hopefully 
more competitive and/or cost effective 
manner. The cost of training is borne by the 
organization and will come out of current 
profits. It is anticipated that this cost will be 
more than offset by the new process once the 
personnel are trained and the "new" system is 
running up to speed. To some extent, this 
type of training is required to provide support 
for space operations. 

3. Increase the overall skill and 
knowledge base of the organization. This 
usually entails allowing the personnel to 
attend seminars or college to work on a 
degree or work related courses. This cost 
comes out of profits and the anticipation is 
for a happier, well educated work force. 

This paper will focus on this last 
reason. Increasing the skill and knowledge 
base will certainly assist in bring about a 


better transition from contractor to customer 
responsibilities. 

Economic Climate 

Everyday you can read about some 
problem in the economy. There is reduced 
spending money for the organization which 
results in an organization folding or perhaps a 
reduction in force (RIF) - layoffs. This is 
becoming even more prevalent in the 
government sector. Criticisms abound with 
paying a government worker and a contractor 
to "work the same job". This is part of the 
reason for transferring more of the jobs from 
contractor to government worker it represents 
an attempt to reduce operating costs. 

Now a rather large decision needs to 
be made, what jobs are to be transitioned?. 
There can be a large learning curve involved 
with the higher technology tasks. In the 

meantime, however; the support type work 
can be transitioned over in a phased 
approach. It needs to be kept in mind that if 
not done correctly, more labor could be 
required to keep from missing deadlines (and 
possible loss of equipment, life and budget. 

Even with transitioning those tasks 
that are considered mundane, there exists a 
requirement for training personnel. 

The following questions now come to 
mind - what type of training is needed?, how 
do the existing personnel get the training to 
keep up with existing technology and do the 
job?, where is the training to come from? 

First we need to look at the type of 
training that can be involved. 

Training Types 

There are four (4) basic types of training that 
will be addressed and these include: 

In-House Training 

In-house training is controlled by the 
internal training department. Here the 
organization must maintain the training 
department and all necessary support 
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personnel (administrative support, training 
developer, instructors.) 

Advantage: training courses can 

easily be developed and geared to a particular 
organization's way of doing business. 
Personnel have knowledge of the 
organization's policies and work load and can 
minimize the amount of time needed to "rack 
the brains" of the in-house experts 
(knowledgeable users) specifics on 
requirements. 

Disadvantage: in tough economic 

times, this department has large cuts or is 
eliminated totally. Additionally, Training 
personnel need to keep up with advances in 
technology and revise material, if the 
department is reduced, who will do this? 

In the case where government 
personnel are to perform jobs previously done 
exclusively by contractor personnel, the 
contractor is the organization with the "in- 
house experts". The government will need to 
receive assistance from the contractor. 

Therefore, in-house development 
would be utilized for the support type 
functions and job assignments. 

Seminars 

Seminars are defined here as those 
instructional courses that are given off-site of 
an organization. Advantage: normally the 

material being delivered is kept up with 
current advances in technology. In good 
economic times, seminars are very good for 
keeping your personnel current with advances 
in technology. There are limitations as to the 
type of courses that can be offered. 
Seminars are usually limited to type of 
technology, not with specifics. For example, a 
seminar on how radar works not a specific 
radar system. 

Disadvantage: This type of training 
can be extremely expensive. For a 30 hour 
seminar it can typically cost $1,200 to 
$1,400 per person. This does not include 
travel, room and board. The employee will 


not be accomplishing any work during the 
time of the training. 

Consultants 

Consultants can provide the needed 
guidance in developing training for use by an 
organization. 

Advantage: Consultants are experts 

in their line of work and are normally well 
versed in extracting information needed to 
develop training and incorporating the 
organization's policies and practices. 

Disadvantage: Consultants, unless 

they are subject matter experts in your 
organization's way of doing business, will 
need to interrupt employees during their 
research. Consultants can also cost a lot of 
money, - money that is not readily available in 
today's economic climate. Typical costs are 
$2,000 a day (plus expenses). 

Traditional Institutions 

Here we will consider the local 
college. In order to stay competitive and 
increase enrollment, are developing state of 
the art training facilities. They are not just 
looking at recent high school graduates but 
personnel in the work force. 

Advantage: Relatively low cost to the 
employer. Provides relatively current and up 
to date technology, though not as quick as 
consultants or seminars. This has to do with 
the process involved in establishing or 
revamping a course. Since the majority of 
courses are given at night, the employee is 
available for completing normal work 
assignments. 

Disadvantage: Cost for establishing a 
new training facility usually not in the 
"Budget”. Remember, colleges also feel the 
impact of the economic climate. 

Training Alternatives 

It is acknowledged that to remain a 
viable, effective organization in today's high 
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technology environment, it is imperative that 
the work force remains trained. This also 
holds true if one wishes to transition work 
from one type of organization to another 
(contractor to government). 

There are numerous alternative ways 
of accomplishing this training. The focus will 
be on three (3) "High Tech" ways: computer- 
based training, interactive video, and long 
distance learning. 

Computer Based Training 

Computer-based training is utilization 
of a computer for direct interaction with the 
student presenting lesson content, providing 
practice and testing student progress. 

Due to the flexibility an capability 
possessed by the computer to provide 
branching instructions, the computer can 
become an infinitely patient tutor. Computers 
can also be used to control other media and 
to provide students with necessary reference 
materials, performance aids, and simulate 
environmental or laboratory facilities. 

Successful computer-based instruction 
depends upon the proper mix of instructional 
content and methods delivered by an 
adequate delivery system. This is 
accomplished by conducting a thorough 
analysis of instructional requirements as well 
as the commitment of time and resources to 
produce quality training programs (and not a 
page turner). 

Computers utilize a variety of different 
interactive terminals or combine other media 
(i.e. video) to present individualized 
instruction. Students may be shown or 
placed in highly simulated environments by 
combining computer capabilities in 
conjunction with other media or equipment for 
purposes of instruction or testing. 

A large number of an organization's 
computing hardware will suffice for the 
running of computer-based instruction, 
thereby reducing some of the acquisition 
costs. 


The major cost would be that of 
development. There are a number of 
software courses available for purchase that 
may be helpful in the training of some support 
type jobs. 

Advantage: For today's problem, 

training in-house personnel with reduced 
spending a form computer based training 
offers a good alternative. A larger number of 
persons are able to be trained with minimum 
employee downtime. 

Disadvantage: Few developers of 

Computer Based instruction are aware of 
certain requirements when developing this 
form of training, as a result, CBI was known 
as a "page turner" and a very costly one. 
Computer-based development costs can range 
from 50 to 500 hours of development time to 
produce 1 hour of student classroom time. 

Where large numbers of students are 
to be taught and/or annual participation is 
required, computer-based training can be 
effective. 

Interactive Video 

This type of training offers realistic 
type of training and can simulate the actual 
work scenario. Flight simulators utilize this 
technology. 

Advantage: This is very useful for 

training people where one mistake can result 
in the loss of money and lives. Or where 
there is one piece of unique equipment and 
training equipment is not feasible. An 
example of this is the current Space Station 
program. 

The Space Station program will utilize 
interactive video with long distance learning. 
Astronauts will be able to read the text and 
watch a demonstration of a maintenance task 
by a diver (neutral buoyancy) while 
performing the task. This is accomplished by 
means of uplink/downlink capability (this is 
taking long distance learning one step 
further). 
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Disadvantage: To come up with an 

hour of training time (using interactive video) 
it would not be outlandish to spend 800 
hours in development time. 

Lono Distance Learning 

This provides instruction to many 
people in many different locales. Long 
distance learning can be accomplished by 
television or by modem, with computer based 
instruction. A common form of long distance 
learning is television courses. Here the 
student can receive all the information that 
the students in the class are exposed to. 

This type of medium can provide two- 
way communication with the instructor, 
which allows for interaction among all "class 
sites". 

No matter which of the "High Tech" 
delivery systems that are employed, it is 
important to recognize that a type cost versus 
benefit analysis is mandatory. 

Additionally, it is important to 
remember that not all training situations lend 
themselves to the aforementioned three ("high 
tech" methodologies. 

Our original question was to find a 
feasible solution to develop and maintain a 
trained work force. If we are currently 
looking at training large numbers of personnel 
with reduced costs there are two (2) 
methodologies to consider. 


Problem 

To develop and maintain a skilled and 
knowledgeable work force even during a bad 
economic climate. Of all the scenarios 
presented, what viable solution or solutions 
are available? 


Solution 

The following addresses two (2) 
plausible solutions that are available and can 
work. 


In-House Training 

In the situation where the organization 
has need of training all its personnel in the 
use of standard office software, computer 
based training has been used successfully. 

The typical training scenario has a set 
schedule for the training class, a limited 
number of students that can effectively be 
taught per session. Due to the fact that the 
classes are held during working hours, no 
shows are typical. Also, the computer 
experience of the students are typically wide 
in range, resulting in some individuals being 
bored, some learning and some lost. To 
offset this, the course would need to be 
taught at three (3) different skill levels. This 
would further reduce the number of students 
actually taking courses at any one time. 

With computer based instruction, the 
course consists of program files, student 
work files and student manual. Once written, 
it costs next to nothing to make copies. The 
make-up of the course can be such as to 
incorporate all three skill levels. People can 
set the schedule for completing the course to 
those times when their work load is lessened. 
The student manual provides a reference book 
for those situations when the individual needs 
to refresh how to accomplish something. 

One organization, uses video in 
conjunction with computer based instruction 
for teaching office software. The result was 
four (4) times as many students were taught 
in the same time frame as previously taught 
using traditional in class training. Specific 
Computer-based courses have been developed 
and employed for courses that are recurring in 
nature (mandatory annual recertification). 


Traditional Institutions (Cooperative Venture) 

The following is a solution that allows 
organizations to maintain skilled and 
knowledgeable personnel. Previously, it was 
brought out that in times of tight money, 
training suffers. The requirement for 
maintaining a skilled labor pool still remains. 
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The problem is - How can 

organizations maintain this tabor pool? By 
cooperative venture with the local college. In 
this scenario, commercial organizations can 
get together with the college and pool 
resources. 

Instead of each organization building a 
state of the art training facility, at each 
individual site, maintaining the facility, 
developing the courses, and maintaining a 
large training staff this is done at a central 
location - namely the college. 

This cooperative provides many 
benefits: (1) the cost of the facility is shared 
by the members of the cooperative, (2) the 
labs are available to the employees of the 
cooperative, (3) the college receives a 
potential increase in student enrollment, (4) 
commercial organization with training at a 
reasonable cost, the cost of a college course 
is substantially less expensive than any 
alternative form of training, (5) the 
commercial organization gets trained 
personnel in utilizing state of the art 
equipment, (6) knowledgeable instructor can 
gear course to individual organization's way 
of doing business (provide examples of how 
to use the information). 

An example of this alternative is 
Brevard Community College (BCC) in Cocoa, 
Florida. Situated in the Space Coast of 
Florida, BCC has numerous technology 
programs. For example. Within BCC's 
Institute for Space Technology there is a 
Logistics Technology program that offers an 
Associates of Science degree in Logistics 
Technology; Hazardous Materials; Quality 
Assurance; Space Engineering. Within this 
program there are courses that, are 
competitive to seminars and provide an 
inexpensive alternative. 

For example a seminar on LSA/LSAR 
ranges from $1295 to $1,400 for 30 hours 
worth of training and give continuing 
education credits. BCC has an LSA/LSAR 
course that is 48 hours in length and gives 3 
college credits and all for $105. 



SEMINAR 

BCC COURSE 

LENGTH 

30 HOURS 

48 HOURS 

COST SEMINAR 

$1,295 

$105 

ROOM/BOARD 

VARIES 

NONE 

AIR 

VARIES 

NONE 

CREDITS 

@3 CONTINUING 

3 COLLEGE 


The above chart shows the potential 
benefits accrued by adopting the cooperative 
venture There is 60% more class time and 
1133% savings in cost of the seminar per 
person. This does not include the savings in 
the other expenses. 

BCC recently completed building a 
state of the art technology facility including a 
computer lab with current releases of 
engineering software, and other forms of 
multi-media equipment. 

BCC, as do other educational 
institutions, are able to set up degree 
programs on the client site. A number of 
colleges in the area of Kennedy Space Center 
offer varying degree programs, as well as 
individual courses, for the specific purpose of 
satisfying educational requirements of 
Kennedy Space Center and do quite well. 

This demonstrates what can be 
accomplished by joining together as a team. 
Not all cooperatives would be set up exactly 
the same; however, the bottom line is that 
industry and educational institutions need to 
work together to survive and prosper in 
today's rapidly changing high technology 
environment. 
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Abstract 

Technological advances during and since 
World War II have created complications to 
the effective accomplishment of logistics 
functions. These complications are due to 
the added functional areas required for 
effective support as well as to the increased 
sophistication required for logisticians. This 
paper identifies the backgrounds of past and 
current logisticians and makes 
recommendations for the educational and 
technical background of future, effective 
logisticians. 

Definition 

Historically "logistics" was defined as: 

" Management Operations and Technology 
associated with the time and place utility of 
men and materials”. 

This definition in the days of simpler 
technology, resolved itself into the provision 
of supplies where and when needed. Even 
when Hannibal crossed the Alps to invade 
ancient Rome, his primary concern in 
making the treacherous journey was to keep 
his troops fed, his elephants comfortable, and 
all healthy so that they could be effective 
fighters. Consequently logistics primarily 
meant "supply" and this philosophy was 
sustained up to and through World War II. 


♦Professor, Industrial Engineering and of Operations 
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The First Kind 

During World War II all able-bodied men 
were called into the military services, in 
effect draining the universities of males. 
The government recognizing this dilemma, 
and, to keep the university operational, 
created programs whereby young men were 
returned to the university in uniform to study 
various relevant areas, one being inventory, 
warehousing, and distribution. Colleges of 
Business picked up on this and recognized a 
profitable area of instruction where industrial 
companies employed these graduates, and 
faculty could research, develop, and further 
improve this approach to logistics. 

Heskett et al (1) from this perspective 
defined logistics as: 

"The management of all activities which 
facilitate movement and the coordination of 
supply and demand. 

Notice the emphasis on supply and 
movement. 


• Principles of Management 

• Marketing 

• Accounting 

• Finance 

• Economics 

• Operations Management 

• Quantitative Methods 

Table 1 : Basic Core Content of the 
Business Administration Degree. 

Table 1 indicates the basic areas of 
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instruction for this first kind of logistician 
while Table 2 shows the specialty or 
"option" areas for this type of background. 


• Warehousing 

• Materials Handling 

• Packaging 

• Traffic and Transportation 

• Inventory Control 

• Order processing 

• Information Flow/Systems 

• Customer Service 

Table 2: Specialties for the logistician of the 
first kind. 


A recent survey (2) indicates that: 

most Colleges of Business Administration 
generally follows this type of content; some 
even specializing their degree requirement 
further (i.e degrees in Transportation). 

The Second Kind 

Colleges of Engineering currently produce 
the second kind of logistician. In the 
engineer’s education emphasis is placed on 
scientific knowledge and technical 
performance and generally, when time 
permits in the curriculum, a rudimentary 
understanding of the necessity for 
deployment (or distribution) operations and 
retirement of the equipment is studied 
Historical precedent is so strong that even 
where the word "logistics" is used it 
generally refers to distribution and inventory 
handling, ignoring the lessons learned since 
World War II. 


Table 3 indicates the general 
academic content of the most current 
engineering degrees. 


• Mathematics/Statistics 

• Chemistry 

• Physics 

• Systems Engineering/Management 

• Human Factors 

• Information Systems/Computer Science 

• Scientific and Engineering Disciplines 

• Economics 

Table 3: Degree content for Logisticians of 
the Second kind. 


While some engineering degrees offer the 
technical knowledge required to become 
effective logisticians, they do not relate this 
knowledge to what actually occurs in the 
"real world" to smoothly transition through 
the phases in the equipment’s life cycle, 
dealing with equipment performance. 

The Third Kind 

During World War II it became evident that 
the deployment of thousands of copies of 
complex equipment could not be adequately 
supported by traditional methods of supply. 
By the time this was recognized it was late 
1944 and there were strong indications that 
the U.S. and its allies would win the war. 
Further, the disruption to ongoing operations 
from major organizational changes was 
considered too risky to the total war effort so 
that the decision was made to reorganize 
after the war was won and demobilization 
had occurred. 

The famous Boeing B-17 "Flying Fortress" 
nicely illustrates the problem. There were 
literally hundreds of B-17’s sent to the 
European theater and the Pacific Theater. 
Each airplane had ten crewman requiring 
training that ranged from two years in length 
to six months. In addition, technical 
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support people, equipment, and facilities had 
to be provided to sustain an effective force. 
Now, when one multiplies this effort by 
literally hundreds of different total systems - 
some larger and some smaller than the B-17 
aircraft, an indication of the complexity of 
the problem is achieved - and it became 
obvious that a new philosophy of support 
was needed to effectively use the national 
resources. This led to the logisticians of the 
third kind. 

In the early 1950’s the first documents 
defining a "Systems Management" approach 
to the development of technological systems 
emerged from newly formed Department of 
Defense. This documentation led to the 
definition of a "System Engineering" 
methodology which in turn changed the 
meaning of logistics from a "Supply" 
emphasis to the broader "Support" definition 
(3). Now the logistician had to be capable of 
meeting the ever increasing dependence on 
high technology aids to solve increasingly 
large and complex problems in the logistics 
domain in order to meet the requirements of 
logistics as defined in DOD Directive 
100.35G (3): 

"... A composite of the elements necessary 
to assure the effective and economical 
support of a system or equipment at all 
levels of maintenance for its programmed life 
cycle . " 

Six years later in 1974, after much debate, 
the Society of Logistics Engineers defined 
logistics as: 

"... The art and science of management, 
engineering and technical activities 
concerned with requirements, design, and 
supplying and maintaining resources to 


support objectives, plans and operations" 

(4). 

Table 4 lists the major disciplines now 
included under the logistics umbrella, 
showing clearly that supply alone is far from 
adequate even on a conceptual basis: 


• Reliability 

• Maintainability 

• Maintenance Planning 

• Support and Test Equipment 

• Supply Support 

• Packaging, Handling, Shipping & 
Transportation 

• Operations and Maintenance 
Instruction 

• Facilities 

• Personnel and Training 

• Computer Facility 

• Funding 

• Management Data 

Table 4: Elements of integrated Logistics 
Support (ILS). 

These elements have been modified or added 
to reflect current technical needs and 
capabilities. 

The scope of ILS is more aptly pictured in 
figure 1 where the X dimension represents 
management requirements, the Z dimension 
is the ILS elements, and the Y dimension is 
the life cycle. Consequently when pictured in 
this manner, the complexities of providing 
adequate support to a large scale, complex 
system can be more clearly seen. In general 
the first kind of logisticians, coming from 
Colleges of Business Administration 
comprehend, more or less, the XY plane 
(Systems Management), while logisticians, 
when they exist at all, coming from 
Engineering Colleges are represented by the 
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Short Term Requirements: 


YZ plane. What is needed for now and the 
fore seeable future are individuals who are 
competent in all three, XYZ, dimensions. 
These will be our future logistics leaders. 


Long Term Requirements: 

College of Business Administration: 

The following are considered the long term 
requirements for logisticians coming from 
colleges of Business: 

1 . Increased awareness between the 
activities in the management of the 
firm and the integrated logistics 
support elements. 

2. Expansion of Systems Management 
awareness to include the notion of the 
life cycle phases and associated 
support requirements. 


College of Engineering: 

1 . Integration of Life Cycle awareness 
and requirements into engineering 
design instruction. 

2. Similarities and differences in life 
cycle requirements for macro and 
micro systems. 

3. Improved awareness of the physical 
distribution environment for all 
engineering disciplines (not just 
Industrial Engineers). 


College of Business Administration: 

The following are considered the important 
short term requirement for college of 
Business Administration: 

1 . Introduction of the notion of product 
or system life cycle and the attendant 
development decision structure with 
its implications for logistics. 

2. Continued emphasis of operations 
management and physical distribution 
topics. 

College of Engineering: 

Colleges of engineering should enhance the 
notions of systems engineering and life cycle 
requirements while clarifying the semantics 
of logistics in Industrial, Electrical, 
Mechanical, Civil, and Chemical Engineering 
programs. 

Conclusions 

1 . While government and military 
systems have maintained their 
currency with logistics changes, most 
of business and industry has not - and 
considerable performance enhancements 
are currently not being achieved as a 
result. 

2. College of Business and/or Management 
need to reinforce the understanding that 
their graduates focus on logistics 
requirements emanating from the design 
phases thus requiring them to satisfy, or 
do the best they can with what comes 
comes out of the engineering phase. 
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Hence they should become involved in 
design activities. 

3. College of Engineering needs to foster 
the comprehension that equipment 
performance needs to be sustained in 
the field and if the equipment cannot 
be supported or maintained performance 
in an ideal environment is useless. 

4. The Logisticians of the Third Kind 
will be the Project leaders of 
tomorrow and the leaders of industry! 
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Abstract 

It has been said that Continual Improvement (Cl) is 
difficult to apply to service oriented functions, 
especially in a government agency such as NASA. 
However, a constrained budget and increasing 
requirements are a way of life at NASA Kennedy 
Space Center (KSC), making it a natural environment 
for the application of Continual Improvement tools and 
techniques. This paper describes how KSC, and 
specifically the Space Shuttle Logistics Project, a key 
contributor to KSC's mission, has embraced the 
Continual Improvement management approach as a 
means of achieving its strategic goals and objectives. 
An overview of how the KSC Space Shuttle Logistics 
Project has structured its Continual Improvement effort 
and examples of some of the initiatives are provided. 


Introduction 

The 1994 KSC Strategic Plan challenges KSC to 
provide safe and efficient space vehicle launch and 
landing, and payload preparation services while 
reducing costs center-wide. The Space Shuttle 
Logistics Project plays an important role in the pursuit 
of inis goal. It is responsible for providing functional 
flight and ground support equipment (GSE) assets to 
the Shuttle Program in support of shuttle processing at 
KSC. These assets are obtained either through the 
purchase or manufacture of new hardware, or by repair 
of existing assets. KSC's prime contractor for orbiter 
logistics is Rockwell International Corporation. 
Rockwell accomplishes the procurement, manufacture, 
or repair of assets either through subcontracts with the 
Original Equipment Manufacturers (OEM), other 
vendors, or at the NASA Shuttle Logistics Depot 
(NSLD) in Cape Canaveral. Rockwell also operates 
the Thermal Protection System (TPS) Facility at KSC. 
KSC s prime contractor for shuttle processing is 
Lockheed Space Operations Company. Lockheed is' 
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responsible for stocking, storing and issuing flight 
hardware which is provided by the Shuttle Project 
elements. They are also responsible for providing 
spares, repair and off-line maintenance for ground 
support equipment (GSE) and facility systems used in 
shuttle processing. 

How Continual Improvement Works at KSC 

KSC initially adopted the Continual Improvement 
management approach in 1991. Since that time, KSC 
has made great progress toward becoming a quality 
management organization. In 1994 and 1995 NASA 
KSC was selected as a finalist in the President's 
Quality Award Program conducted by the Federal 
Quality Institute. This award program recognizes 
federal government organizations that have 
implemented quality management and achieved high 
levels of customer satisfaction. 

KSC's approach to Cl features both top-down and 
bottom-up aspects. A KSC Continual Improvement 
Plan was published in 1994. This plan establishes the 
framework by which KSC can balance the original 
employee driven Cl efforts with that of a management 
driven approach. Not only are employees encouraged 
to identify and implement process improvements in 
their own work areas, but each organization's 
management is challenged to select processes critical 
to the successful performance of their organization. 
Teams are established to evaluate these processes using 
the Cl tools and techniques such as process analysis 
through flow charting, establishment of baseline 
measurements, identification and implementation of 
improvements and continual performance monitoring. 
Candidate critical processes for such improvement 
scrutiny are identified at the directorate level and 
presented to the KSC Cl Steering Committee for 
approval. This senior management review assures 
consistency with the KSC strategic goals and the Cl 
efforts of other KSC organizations. 

The Shuttle Logistics Project abides by the Cl 
strategies of the KSC Cl Plan. Shuttle Logistics has 
found that integrated process improvement teams 
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which include representation from both NASA and the 
contractor are most beneficial. Several successful 
initiatives also included personnel from other NASA 
centers such as Johnson Space Center (JSC). Just some 
of the many Cl initiatives conducted by the Shuttle 
Logistics Project follow. 

Continual Improvement Success Stories 
Direct Buv Initiative 

Procurement of spare parts for orbiter processing and 
for establishing repair part inventories at the vendor or 
the repair facility is a key process within the KSC 
Shuttle Logistics Project. An investigation into this 
procurement process resulted in a very successful 
improvement initiative known as the Direct Buy 
Program. The purpose of the Direct Buy Program is to 
reduce spares costs through purchase of parts directly 
from the actual manufacturer when there is no unique 
added value provided by the subcontractor of the next 
higher assembly. This reduces the procurement lead 
time as well as eliminating redundant tasks in several 
areas such as procurement administration, receiving 
inspection and engineering. 

Since it is essential to maintain the integrity of the 
systems and equipment in which direct procured parts 
are to be used, the Direct Buy Program itself involves a 
process. The Logistics function initially screens for 
repetitive procurements and projects direct buy savings 
potential for each spares candidate. The screened 
items include Line Replaceable Units (LRU’s), Shop 
Replaceable Units (SRU's), and piece parts. From this 
screening, a direct buy spares candidate listing is 
established. Once direct buy candidates are identified, 
they are evaluated by an integrated technical team 
representing Logistics, Engineering, Product 
Assurance, Reliability, Configuration Management and 
Material. JSC Subsystem Managers, OEM’s and then- 
subcontractors are also represented in this technical 
review. The team uses a standard criteria to assure 
direct procurement is the optimum method of acquiring 
the part. This direct buy analysis includes an 
evaluation of the technical data availability, currency 
and ownership; categorization of the part as either 
specification controlled or commercial; assessment of 
the value added by the current supplier; evaluation of 
the design maturity/stability and a cost analysis. Once 
a direct buy candidate passes all of the technical and 
financial screening criteria, the approval cycle begins. 
This approval process involves both KSC Logistics 
Project Management and JSC Orbiter Project 
Management. 


As in any quality management organization, methods 
of improving and streamlining the Direct Buy Program 
candidate selection and approval processes are 
continually investigated. For example, the mature 
Direct Buy Program was averaging a process flow time 
of 45 days from screening efforts to management 
approval for direct procurement implementation. 
Analysis of the processing flow reduced this time to 
less than 25 days. 

The Direct Buy Program has already resulted in 
significant tangible savings and the anticipated cost 
savings through the life of the Shuttle Program are 
even greater. Since the Direct Buy Program was 
implemented in 1991, it has shown a positive return on 
investment, with program savings (as of June 1994) in 
excess of $2.7 Million. The projected savings through 
the life of the Shuttle Program are estimated to be 
nearly $8 Million. This figure only represents 
continuing the direct procurement of those items 
already approved, and does not consider possible 
savings to be achieved by application of the direct 
procurement approach to additional candidates or 
newly designed systems/hardware. 

Thermal Protection System (TPS) Initiatives 

Each Shuttle Orbiter has approximately 24,000 
protective tiles over its outer skin. These tiles, as well 
as soft-goods, make up the Orbiter's Thermal 
Protection System (TPS) which protects the orbiter 
from the heat of re-entry and the cold soak of space. 
TPS components are manufactured and/or repaired at 
KSC in the TPS Facility. A team of KSC workers in 
this facility has undertaken several initiatives which 
have resulted in, or will result in, significant monetary 
savings to the Shuttle Program. Of primary 
significance are the team’s efforts related to tile 
Production Unit (PU) production. PU’s are the larger 
blocks of TPS tile material from which the individual 
Space Shuttle tiles are machined. In the past, tile PU’s 
have been procured from an outside vendor at an 
estimated cost of $3,000 per PU. 

Flight-certifiable PU’s, as well as non-flight PU’s, are 
used in the day to day operations in the TPSF. Non 
flight tiles are used frequently in testing and as 
manufacturing aids. The TPSF team developed the 
capability necessary to manufacture non-flight PU’s 
from recycled silica waste materials. The team’s 
innovation and cost consciousness resulted in 
refurbishment and adaptation of excessed equipment 
from KSC and other locations in order to develop this 
recycling and fabrication capability. No longer using 
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the costly flight-certified PU’s for this purpose has 
resulted in an estimated savings in excess of $500,000 
since the initial prototype non-flight PU was completed 
in 1993. 

The team’s success in non-flight PU production opened 
the door to certifying the TPSF for the manufacture of 
flight-certifiable PU's. KSC has proven that it has the 
resources, space, and capability to do such 
manufacturing, and has received Shuttle Program 
authorization to proceed. All of the raw materials are 
on hand. KSC is in the process of acquiring all of the 
necessary equipment, making required facility 
modifications and finalizing manufacturing specifi- 
cations. Plans call for the completion of the 
certification effort by September 30, 1995. 

Certification of the TPSF for PU production will better 
facilitate the "just-in-time" manufacture of tiles for 
replacement during orbiter processing. Additionally, 
significant Shuttle Program savings will be achieved by 
not having to procure the PU’s from an outside vendor. 
The team estimates that this savings could be as much 
as $6.5 Million. 

GSE Quick Disconnect (OD1 Repair Relocation 

In order to ensure the integrity of shuttle flight 
systems, often the GSE is subject to stringent periodic 
maintenance requirements. Due to the risk of flight 
hardware contamination, QD's on the hydrazine 
servicing carts and the Mobile Launch Platform 
hydraulic panels require annual refurbishment. Until 
September of 1993, these QD's were returned to the 
OEM for this scheduled maintenance. However, 
escalating costs and lack of responsiveness by the 
vendor prompted KSC to seek alternative means of 
accomplishing this task. Lockheed Supportability 
Analysis initiated an investigation into transitioning 
the repair site from the OEM to KSC’s on-site 
subcontractor for precision cleaning, Wiltech. This 
resulted in another integrated team effort including 
logistics, engineering and the cleaning facility 
personnel, culminating in an effective transition of the 
repair site and significant cost savings for the Shuttle 
Program. The average repair turnaround time at the 
vendor was 420 days at a cost of $5,300 per QD. On- 
site QD repair has reduced this turnaround time to 38 
days with significantly reduced costs estimated at 
$1,300 per QD. Cost avoidance of $275, 000 is 
estimated due to not procuring fifteen additional QD's 
which would have been necessary in order to continue 
to support shuttle processing with the excessive repair 
turnaround time. The annual cost savings of repairing 
on-site is estimated to be $ 1 80,000. 


Air Data Transducer Assembly (ADTAVSRU Repair 
Process Improvement Team 

The ADTA is a subsystem of the Orbiter’s Avionics 
System, which provides guidance, navigation and 
control information on the movement of the orbiter 
through the atmosphere. This subsystem senses air 
pressures related to spacecraft movement through the 
atmosphere necessary to update navigation state vector 
in altitude; provide guidance in calculating steering 
and speed brake commands; update flight control law 
computations; and provide display of other essential 
flight parameters to the shuttle commander and pilot. 

A concern over the increasing turnaround time for the 
repair of failed ADTA SRU’s prompted the formation 
of a process improvement team to evaluate and 
improve the repair process at Allied Signal Controls 
and Accessories (ASCA) of Tucson, Arizona, the OEM 
for the ADTA'S. This effort is an excellent example of 
a supplier striving to assure customer satisfaction by 
forming a partnership with its immediate and extended 
customers in an endeavor to reduce the cycle time for 
repairs without increasing costs. In August 1994 a 
thirteen member integrated team of NASA (KSC and 
JSC), Rockwell and Allied Signal personnel was 
formed to review, analyze and improve the repair 
process, with particular emphasis placed on reducing 
the repair cycle time by 50%. 

The team’s focus is on the repair process for the 
transducer components of the ADTA. The baselined 
average repair turnaround time for one transducer is 
280 days. The team established a goal of 150 days 
based on their understanding of process capabilities 
and support requirements for shuttle orbiter processing. 
Allied Signal's process improvement/problem solving 
model. Total Quality through Speed (TQS), is being 
used in this initiative. This involves a nine step 
approach to process analysis and improvement. 
Process input and output boundaries are defined and 
process flow charts developed. Potential process 
barriers and root causes of process problems are 
identified with proposed solutions. As solutions are 
implemented, the repair turnaround time must 
continue to be monitored to evaluate the success of the 
process improvements. The first transducer since the 
start of this improvement initiative was sent to Allied 
Signal in late September. At the time of this writing, 
the team is mid-way through the nine step process. 


American Institute of Aeronautics and Astronautics 


203 


Make: vs Buy Decision Process Improvement Team 


Conclusion 


Once it has been determined that a part is needed, a 
decision is made as to whether or not the part will be 
manufactured at the NASA Shuttle Logistics Depot 
(NSLD) or procured from an outside vendor. Ideally, 
all relevant factors are considered and an optimum 
decision is made. This make vs. buy decision process 
was selected as one of the Shuttle Logistics 
organizations critical processes by KSC management. 
An integrated team of NASA and Rockwell personnel 
has been chartered to review and improve this decision 
process. The team is chartered to document the 
existing process, define relevant decision factors, take 
action to streamline and improve the process, and 
continue to measure the effectiveness of the decision 
process. At the time of this writing the team is in the 
initial stages of process definition and analysis. 

Shop Floor Data Collection System Initiative 

KSC technicians that perform shuttle processing tasks 
to prepare the vehicle for its next flight could be 
considered logistics most important customers. The 
proper parts, materials and tools must be available to 
the technicians at the proper location and at the 
scheduled initiation of the task in order to avoid 
processing delays. The Shop Floor Data Collection 
System (SFDCS) is an integral part of KSC's 
Integrated Work Control System (IWCS). The SFDCS 
is used to collect data on task duration and delay 
occurrences and durations, for work conducted at the 
major shuttle processing facilities such as the Orbiter 
Processing Facilities (OPF), Vehicle Assembly 
Building (VAB) and the launch pads. As delays are 
experienced, operations personnel enter this data into 
the computer system using a specific delay code. The 
system can be used to provide real-time status of 
processing activity, but more importantly, the data 
collected can be used to drive process improvements. 
Logistics and operations personnel have recently joined 
together in the evaluation of the data indicating 
logistics-related delays. At the time of this writing, 
this effort is just getting underway. There is reason to 
believe that the data already being collected by 
operations personnel can provide the Shuttle Logistics 
Project with an indication of customer satisfaction, as 
well as pin-point opportunities for improvement in the 
processes associated with providing parts and materials 
to the shuttle processing floor. 


The KSC Shuttle Logistics Project has been very 
successful in implementing the Continual Improve- 
ment approach to quality management. KSC’s Shuttle 
Logistics Project strives to enhance process 
performance and ensure customer satisfaction through 
the use of Cl tools and techniques for process analysis, 
improvement and measurement. Significant monetary 
savings, greater process effectiveness, and customer/ 
supplier partnerships have already been realized. 
Focus on quality management will continue as KSC 
conducts its complex mission and pursues its ambitious 
goals with less resources. 
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Abstract 


Total Quality Management (TQM), is easily 
understood, can be implemented in any type 
of business organization, and works. This 
can be seen when one stops to realize that 
TQM has been around quite a long time and is 
increasingly being embraced by all forms of 
organizations, both profit and non-profit. It is 
being recognized that TQM can help an 
organization continue even in a tough 
economic climate. 

The purpose of this paper is to show the 
reader what TQM is and how to apply Total 
Quality in the Space Systems and 
Management arena. 

Introduction 

Process Analysis Techniques, Metrics, 
Baselining, Quality Assessments, Customer 
Satisfaction Continuous Improvement these 
are just some of the terms that are associated 
with Total Quality Management. Throughout 
recent years, there have been a number of 
theories or "management techniques" (non 
TQ) that have surfaced to make "companies 
better and more profitable". 

It seems that the majority of these techniques 
do not stay around long enough or are not 
easily adaptable to be utilized by the different 
type of business organizations. These "non- 
TQ" techniques are developed and 
implemented in high manufacturing, 
manufacturing environments and are not 
easily adaptable to other types of 
environments. TQ on the other hand, is easily 
adaptable to all forms of organizations. 

Copyright © by the American Institute of Aeronautics 
and Astronautics, Inc. All rights reserved. 


This paper addresses the following topics and 
concepts that provide for easy implementation 
of TQM: 

o Total Quality Management 
definition 

o Teams and Partnerships 
o Types of Teams 
o Process Analysis Techniques 
o Disciplined Systems and Processes 
o Total Quality Implementation 
o Process Management 
o Baselining 
o Metrics 
o Teaming 

o Quality Assessments 
o Process Flow Charts 


What is Total Quality Management? 


CUSTOMER FOCUS 
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Total Quality Management consists of (1). 
Change - Changing paradigms: work smarter 
not faster, look for process problems and 
people problems, encourage participative 
management. (2). Repeatability - Well defined 
processes, consistency. 13). Productivity - 
Defined, measured, how can we increase it? 
(4). Quality - Defined, measured, defect 
detection then prevention. (5). Customer 
focus - Everything you do has a customer, are 
your customer requirements defined? Is your 
customer satisfied? What are the gaps 
between what you provide your customer and 
what they want, or even what they need? 

Total Quality - A customer-focused, 
systematic approach to continuous 
improvement. It represents a management 
philosophy that encourages teamwork, joint- 
problem solving, communication, trust and 
continuous improvement of products and 
services. It is known by its use of analytic 
techniques, particularly statistical methods, to 
provide an objective reason for process 
monitoring and change(s). 

The main thrust of TQM is in that of 
Customer Satisfaction. Customer satisfaction 
deals with delighting you customer. Since an 
organization is typically exchanging a product 
or service for money, it is important to 
remember your obligation to your customer. 
The customer is the one who defines quality. 
It is the contractor's responsibility to ensure 
that the quality of the product or service is 
meeting and exceeding the customer's needs 
and expectations. 

It is important to recognize who your 
customer is both internal and external to the 
organization. To properly understand the 
customer's needs and expectations, you need 
to recognize their place in your organization. 


SUPPLIER 

i— 

PROCESS 
(YOU ADD VALUE) 

H 

CUSTOMER | 


Recognizing your customers place in your 
organization, allows you to determine your 
customer's needs and expectations. 

For example: Lets say an organization has 
100 employees, sells 200 widgets a week, 


orders 1 000 items a week and that this is a 
90% perfect organization, there would be: 

1 0 employees not paid per week 
20 widgets not being delivered 
on-time 


1 00 items not received a week 

It can be easily seen that this 90% perfect 
organization is unacceptable. There are quite 
a number of unsatisfied customers. 


An expansion of this philosophy is known as 
Continuous Process Improvement. 

Continuous Process Improvement is a 
methodology whereby an organization 
describes in detail the processes necessary to 
carry on the organization's business. It 
assists in "weeding the garden" by identifying 
short comings in the organization's way of 
doing business. With the incorporation of a 
feedback mechanism, it is possible to modify, 
add and/or delete processes. 


CONTINUOUS PROCESS IMPROVEMENT 



The "Best in Industry" organizations have 
embraced and practice Total Quality 
Management. To help an organization trying 
to incorporate Total Quality and attaining 
improvement, it is important that all 
individuals in the organization learn, accept 
and practice TQ in order for the transition to 
work. This includes the development of 
teams and partnerships. As mentioned 
previously, no one individual, in an 
organization, works in a vacuum and does not 
have any customers. 
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Teams and Partnerships: 

The Total Quality effort within any 
organization needs to have a structured 
controlling procedure. This usually takes the 
form of a [top-level] Executive Steering 
Committee and continues on through the 
organization to the lowest levels in the form 
of subcommittees, and teams. This process 
allows the organization to address quality 
related issues at all levels and promotes 
employee involvement. 

The Executive Steering Committee would 
have the following responsibilities: 

o Develop the TQM Implementation 
Model (these are the steps that are followed 
to implement TQM) 

o Write the plan for attaining TQM 
which entails writing the strategic objectives 
necessary to improve the organizations way 
of doing business this includes identifying 
organizational goals and objectives based on 
customer inputs, evolution of the business 
cycle and employee feedback. 

o Be the formal delegation of 
authority to charter cross-organizational 
teams. 

o Review the status of the TQM 
implementation process 

There can be steering subcommittees at all 
levels of management, as needed, to assist in 
formally addressing quality issues at the 
various levels within the organization. Using 
the critical processes and identified problem 
areas as targets for continuous improvement 
activity, the subcommittees in each 
department perform tactical planning for total 
quality improvements. 

Operating Levels 

This level is comprised of functional groups, 
individuals and teams conducting TQ 
activities. The TQ process is worked through 
the establishment of permanent, temporary, 
or Ad-Hoc quality improvement teams. 
Permanent teams known as task teams or 


integrated product teams (IPT), are cross- 
functional in nature and are organized to 
develop and produce specific systems or 
subsystems. The composition of the IPT 
leads to an interdisciplinary cooperation that 

reduces product development cycle time and 
defects. 

It is important that the steering committees 
utilize the expertise of the employees at all 
levels to solve problems and improve work 
processes. 

The Steering Subcommittee is the vehicle for 
the chartering of process teams who tasks are 
to identify, define, measure, and improve the 
organization's critical work processes. 

Steering subcommittees also monitor teams 
and report on status. 

Types of Teams 

Successful teams recognize the need for 
utilizing a structured approach which includes 
clearly defined roles and responsibilities of its 
members. The following delineates categories 
of TQM team membership: 

TQM (Process) Specialist: Supports 
the team in planning, team methodology, 
metrics, 

TQM training, and team process. 
Coaches the Team Leader. 

Leader/Facilitator: Orchestrates team 
logistics, presents status, is the focal point 
for team activities. Steers the discussion 
ensures the members remain focused on the 
problem at hand. 

Facilitator: Keeps the discussion 
focused. Controls dominating team members, 
keeps the leader in charge. Elicits responses 
from overlooked members. Brings 
discussions to a close. 

Recorder: Records the minutes of the 
meeting. Can be a permanent or a rotating 
responsibility, 

Member: Contributes ideas and 
efforts. Works actions. 
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Process Action Teams - Target a specific 
process for improvement using a structure 
methodology that emphasizes baselining, 
measuring and standardizing. 

Development Teams - May address processes 
or systems that are unclear, poorly 
documented, or not yet in place. 

Tiger teams - These teams solve critical 
problems needing short term resolution. 

Temporary teams are normally formed and 
chartered for specific problem-solving or 
process analysis issues, these teams follow 
structured TQ approaches that are tailored to 
enable a team to achieve its charter. 


Integrated Product Team - this concept 
realigns vertical organizational structure 
centered around functions to horizontal teams 
focused on specific elements of the product. 

Quality Action Teams - composed of 
employees who are tasked with resolving 
specific problem areas and issues. This type 
of team is focused toward achieving feasible 
solutions, and is disbanded when their charter 
is fulfilled. 

Process Management Team (PMT) - this team 
addresses much broader issues than quality 
action team and can have a much longer life. 


The Process Analysis Technique is made up 
of the following: 


PROCESS ANALYSIS TECHNIQUE 


DEFINING THE PROCESS 


3 


o Describe the process 
o Establish process bundaries 
o List key external inputs and suppliers 
o List key external outputs and customers 






DOCUMENTING THE PROCESS 


3 


o Document the flow of activities within the process boundaries 
o Construct process flow chart and/or logic flow chart 

o List requirements for each input and output and internal specifications fro each activity 
o Determine if there are measurements for each requirement and specification 


EVALUATING AND IMPROVING THE PROCESS 


3 


o Analyze and evaluate the process 
o Commit to improvements 


American Institute of Aeronautics and Astronautics 



Disciplined Systems and Processes 


The organization needs to focus on defining 
and improving processes. A process is a 
definable set of tasks which produces 
measurable outputs. A system is a set of 
processes that work together to produce a 
specific output: 



SYSTEM 


A set of processes is known as a system if 
the processes work together to produce a 
specific output. Determine what makes of a 
disciplined system or process. 


Identify some critical processes that each 
functional group within the organization 
controls that could be improved. Take one of 
the processes that were identified and list the: 
Supplier, Input, Output and Customer. Next 
list (1).. the task that initiates the process, 

(2). the task that ends the process, and (3). 
any applicable intermediate tasks: 



To improve work processes it is important to: 
o Identify critical processes 
o Baseline (define and measure) 
critical processes 
o Improve critical processes 

It is important to know that Process 
Improvement is measurable it has to be to be 
able to see if its working. 



Process improvement can include: 
o Reducing cycle time 
o Reducing costs (workhours including 
reducing rework and materials including 
reducing scrap) 

o Reducing defects 
o Meeting schedules 
o Meeting budgets and estimates 

The following represents the common 
elements of TQM: 

1 . Management leadership 

2. Management style change to encourage 
employee participation-participative 
management 

3. Focus on customer needs 

4. Emphasize process problems and not 
employee blame 

5. Requires prescribed improvement plans 

6. Uses statistical methods for process 
improvement 

7. Quality is directly related to productivity 
and inversely related to cost 

Changing Environment: 

One of the most difficult things an 
organization can effect is change. It is known 
that individuals have a hard time coping with 
changing the status quo in the work 
environment. Resistance to change usually 
rears its ugly head. This is true when the 
employee feels that change will force that 
individual to "release information" that was 
known only to him/her. This interpretation of 
protecting one's job. So the individual 
employee ask - Why change? 

Change, however, can be very beneficial. In 
today's economic climate, there are less 
dollars budgeted for existing programs and 
future programs. In reaction to this, 
organizations are attempting to scale down 
day to day operations while increasing 
productivity. 
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The reasons why an organization needs to 
change is as follows: 

o Competition 
o Budget/Profit 
o Technology 
o Customer Needs 
o Efficiency 
o Development 

Competition - with less money available, 
competition is increasing. We see where 
large corporations are merging in order to 
obtain a competitive edge. 

Budget/Profit - if an organization is left 
running "status quo", and less monies are 
available, it can be seen that profit cannot 
remain the same. To increase profit - change 
is eminent. 

Technology - the world today is experiencing 
rapidly changing technologies, it is imperative 
that, for an organization to remain marketable, 
that the organization acquire the newer 
technology in an expeditious manner. 

Customer Needs - in years past customers 
relied on the recommendations of the supplier 
of products or services, what was given was 
what not always what was needed. It is 
important for the supplier to become aware of 
what the customer needs. Change is 
warranted in the way the supplier deals with 
customers. 

Efficiency - to remain competitive, an 
organization needs to increase efficiency. 

This could mean that the every day processes 
be reviewed for shortcomings, then either 
modify or develop new ones. 

Development - Expansion of the organization 
is accomplished through change. 

Ever increasing demands from the customer 
added to ever increasing costs will usually 
force an organization to one of three 
alternatives. 

1 . The organization decides that the 
increasing demands and expectations of the 
customer are unreasonable. 


This results in losing the customer, lost 
revenue, loss of profits, potential loss of other 
business with a potential bottom line of the 
disbanding of the business. 

2. Organization could reduce the quality of 
the products and services in order to reduce 
costs. This results in losing the customer, lost 
revenue, loss of profits, loss of other business 
with an almost assured bottom line of going 
out of business. 

3. The organization could strive to exceed 
the customer's demands and expectations, 
and simultaneously lower costs incurred by 
the organization by improving work 
processes. This would allow for development 
of the organization and increases the 
probability of acquiring more business from 
existing customers and business from new 
customers. 

Total quality Implementation Approach 

Involve the application of TQ principles as an 
integral part of your day-to-day way of doing 
business. The type of business the 
organization engages in will dictate the 
approach taken to satisfy their unique 
operational needs and environment. The 
organization needs to a), identify their 
customer's top level requirements and 
expectations for each business area, b) 
identify the key processes and infrastructure 
drivers that determine their outcome, and c) 
develop metrics and closure plans to ensure 
each of these key processes and drivers are 
the "Best in Industry" 

Process Management 

Every supervisor needs to be focused on 
improving the quality, reducing the cost, and 
shortening the cycle time of the key 
processes they manage and support. These 
efforts need to be in-line with top-level 
objectives that drive the organization's 
bottom line and need to be in support of 
internal and external customer requirements. 
If your area's output is not directly linked to 
the organization's business objectives, 
selection of the process can be based upon 
one or more of the following criteria: 
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o 


o 


o 


o 


o 


The process has the greatest 
impact on the organization's 
key customers), or, 

The process creates the 
greatest demand on the 
organization's resources, or. 

The process is a high priority 
according to the upper 
management, or. 

The process most adversely 
impacts organization's 
adherence to schedule 
Individual components need to 
accomplish the following: 

Define their key process, and 
identify related customer 
expectations 


o 



o 


Establish metrics for 
baselining, benchmarking and 
improving the performance of 
their key process 

Set improvement goals, 
provide the required 
resources, monitor progress 
and take actions to achieve 
the planned improvements 


processes, rank them by criticality and 
develop flow charts. The flow charts are to 
delineate the inputs an suppliers, customers 
and products, process metrics, and cycle time 
for each process. This information is used as 
the baseline which is used to analysis any 
process flow for potential streamlining 
activities. 


Metrics 


The top-level operating organization needs to 
develop and track appropriate metrics on 
those key processes that support their 
customer's top-level requirements and 
expectations for each business area. The 
metrics should be operational in nature and be 
predictors of the processes desired outcomes. 

Each functional area, in turn, needs to also 
develop and track the appropriate metrics on 
those key processes that support your 
customer's top-level requirements and 
expectation for their department's mission. 

A TQM metric defines the unit in which a 
characteristic or an attribute of a work 
process is measured. TQM metrics can be 
categorized along several dimensions - by 
what the metric is supposed to measure; by 
the type of measure (physical nature or units 
of the metric); by the purpose of the metric. 


o Gain employee participation 
and teamwork and partner 
with both internal and 
external customers and 
suppliers by actively 
solicitating their involvement 
in process improvement 


o Establish process improvement 
and customer satisfaction 
goals with employees as 
part of the performance 
management and 
compensation process. 


Baselining 


At the functional level within the organization, 
functional components identify all work 


These metrics need to be displayed so that 
everyone in the organization have ready 
access to how the group or operating unit is 
progressing towards accomplishing its stated 
objectives and goals. 

Top-level reviews by appropriate senior 
management from the organization are 
recommended on a monthly basis to assess 
progress and implement corrective action as 
necessary. 

Identification of suitable metrics within a 
process is critical to resolving problems. 
Wrong or irrelevant measures lead to a waste 
of time in data collection and chasing the 
wrong problem. 
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Types of Process Metrics 

Productivity- This characteristic deals with 
measuring units of output per fixed units of 
inputs (fixed level of effort) It measures how 
much work is accomplished and is based on a 
fixed effort. An example would be how many 
pages of text are completed in a maintenance 
manual by the first in-process review. 

Quality - This characteristic deals with 
measuring the degree to which a customer's 
requirements are satisfied. Discrepancies 
where requirements are not satisfied are used 
as a quality measure. This type of metric 
depicts how well a process is working. An 
example is also in technical publications 
measuring the number of pages per comment. 
This provides a measure of rework. 

Timeliness - This characteristic deals with the 
amount if time it takes to complete the 
various steps of a process, particularly in 
regard to performance against a schedule or 
estimated time to completion. This metric 
addresses the "how prompt" aspect of a 
process. An example of this would be how 
many days it takes to get a CDRL deliverable 
through the review cycle. 

Reliability - This characteristic deals with the 
degree to which a process performs its 
functions over a stated time period. This 
metric is based on errors or failures per fixed 
time. Reliability addresses the "how long 
does it work" aspect of a process. An 
example would be the Mean Time Before 
Failures (MTBF) for a piece of prime mission 
hardware. 

Metrics can be categorized along several 
dimensions: 

o what is the metric supposed to 
measure? 

o what is the type of metric? 

o what is the purpose of the metric? 
After establishing process metrics, the next 
step is deciding on the arithmetic category in 
which the metric data is to be collected. The 
nature of the metric can usually determine the 
arithmetic category. 


A process metric can be divided into one of 

two types of categories: 

o Attribute data - A metric is classified as an 
attribute if it represents or is computed 
directly from categorical data. 

TYPES 

1 ) Simple count 

2) Classification 

3) Percent 

4) Ratio or count per 

EXAMPLES 

1 ) Number of lines of code written 

2) Success or Failure 

3) Operational Availability 

4) Comments per document page 

o Variables data - A metric is classified as a 
continuous variable if it represents the 
measurement of a characteristic over a 
continuum. Processing time can be a 
continuous variable when measured to a 
high degree of precision. Types of variable 
metrics include: 

TYPES 

1) Continuous measurement of dimensions or 
time 

2) Rates or time rates 

EXAMPLES 

1 ) Length, width, height, weight 

2) Single lines of code per man-month 


HOW DO METRICS WORK? 
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Metrics depict a pictorial representation of a 
process, and when designed correctly, 
provide a feedback that allows for: 1 . Error 
detection, 2. identification of the causes of 
the error, 3. corrective feedback mechanism, 
4. improvement and adjustment capability. 

Metrics provide useful information and can be 
applied very successfully and parallels the 
effort comprising Continuous Process 
Improvement. 

Teaming 

The application of Integrated Product Teams 
(IPT) is encouraged. Organizational planning 
should include strategies for IPT 
implementation and goals. To expand the role 
of participative leadership, it is advisable to 
encourage employee participation and 
involvement in quality improvement teams. 
Team activities need to be linked to the 
satisfaction of key business objectives and/or 
areas critical to the group's mission or 
charter. 


Quality Assessments 

The primary responsibility for TQ 
implementation rests with each functional 
element. The Total Quality lead provides 
guidance as to the approach and deployment 
of the organization's overall total quality 
strategy. To achieve a common 
understanding across all functional areas, the 
oversight process is conducted along three 
dimensions of approach, deployment and 
results. 

Approach refers to the functional area's 
leadership action having defined methods for 
total quality implementation tailored to the 
unique operational needs and special 
environment of the organization. 

As a minimum, the approach needs to outline 
the strategy for linking the organization's 
business goals to every affected manager. 

Deployment refers to the communication of 
the approach to employees with management 


responsibilities for improving their key 
processes in the near term and beyond. 
Results refers to having completed baselining 
the process being improved and showing 
process performance trend data. 

Process Flow Charts 

Flow charts are used to obtain a better 
understanding of each component of a 
process and to determine how each 
component contributes to the process 
structure. Flow charts depict the overall 
process better and make it clearer. Flow 
charts make it easier to identify a problem 
area(s) contained within a process. They can 
be used as a training tool to show involved 
individuals what the process is about. They 
are used as the vehicle to document the 
process. Flow charts are used to identify 
solutions to a problem by modifying the 
sequence of flow within a process. 

Flow charting represents a key component of 
baselining a process. The flow chart 
represents a pictorial view of a process and 
depicts how the process flow takes place. 
Process flow charts show components (or 
functions) within a process, the relationship 
among these components ((or functions) and 
any precedence. Flow charts depict the steps 
involved in the process. 

The following is an example of a flow chart 
for generating a MRSA Output Report. 
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What wasn't discussed was what to do with 
all the information that is collected when 
incorporating TQ. The information becomes a 
sturdier foundation upon which to build the 
organization. 

This is accomplished by the integration of the 
overall customer and organization's 
operational performance requirements. 
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The following picture, known as a Quality 
Excellence Wheel, displays a foundational 
basis for integrating the overall customer and 
organization's operational performance 
requirements 



It should be noted that TQ has evolved and 
will continue to evolve as time goes on. It is 
important to recognize the components that 
comprise TQ and to use them to their full 
advantage. It is very important that all 
individuals in the organization learn, accept 
and practice TQ in order for it to work. 

1 . Identify and list your suppliers 

2. Identify and list your customers 

3. Identify and list your critical processes 

4. Prioritize your most critical processes 

5. Baseline (define and measure) the most 
critical processes 

6. Get a buy-in from your customer (solicit 
customer and supplier input and feedback 

7. Improve the most critical processes 

8. Measure the improvement 
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